| 00:35 | <gsnedders> | Is there any public date for the start of Apple's work on JSC (and what would become WebKit in general)? |
| 00:37 | <gsnedders> | Because what sources I can find put it as 2001. Just wondering when the decade anniversery is. :) |
| 00:38 | <gsnedders> | 08/24/2001 07:24:40 (10 years ago) would appear to be it from SVN |
| 01:11 | <bga_> | gsnedders while(foo){ const с = expr } |
| 01:12 | <bga_> | logically expr should be assigned to с each time |
| 01:12 | <bga_> | but not |
| 01:12 | <bga_> | *assigned*, not alloced |
| 01:13 | <bga_> | but direct assign c = 1 w/o const keyword - forbided |
| 01:16 | <bga_> | hm |
| 01:17 | <bga_> | heh fix a = 1; a = 2; _log(a) |
| 01:17 | <bga_> | in opera - 2 |
| 01:17 | <bga_> | in chrome - 1 |
| 01:17 | <bga_> | s/fix/const/ |
| 01:18 | <bga_> | in ff - 1 |
| 01:18 | <bga_> | :( |
| 03:00 | <gsnedders> | bga_: Lars Thomas Hansen (of ES4 fame) apparently originally didn't want to implement const as it was non-standard, then site compat started requiring it, so made const a synonym for var, and that seems to have stuck around through the whole engine being rewritten since. |
| 06:58 | <hsivonen> | this has nothing to do with HTTP headers, right: http://bugzilla.validator.nu/show_bug.cgi?id=839 ? |
| 06:59 | <MikeSmith> | hsivonen: indeed |
| 07:14 | <MikeSmith> | hsivonen: fyi, I pulled all your latest changes into the backend for the HTML5 facet of the W3C validator |
| 07:16 | <hsivonen> | MikeSmith: cool. any user complaints yet? |
| 07:16 | <MikeSmith> | nope |
| 07:16 | <MikeSmith> | but I just did it only 15 minutes ago |
| 08:15 | <hsivonen> | MikeSmith: I updated the validator code with new meta name registrations. I also replied to the bug report by the pagerank-seo guy. |
| 08:15 | <MikeSmith> | OK, saw the checkin |
| 08:15 | MikeSmith | takes a look at bugmail |
| 08:17 | asmodai | is still unsure why nightly (7.0) and aurora (6.0) can't run next to each other even with -no-remote |
| 08:18 | <hsivonen> | asmodai: you need -P with different profiles in addition to -no-remote |
| 08:18 | <hsivonen> | e.g. -P aurora -no-remote and -P nightly -no-remote |
| 08:18 | <hsivonen> | asmodai: see also https://bugzilla.mozilla.org/show_bug.cgi?id=655667 |
| 08:20 | <hsivonen> | asmodai: no version of Firefox can deal with two app instances accessing one profile concurrently |
| 08:20 | <asmodai> | Well, I have 3 profiles set up when the profile manager pops up |
| 08:20 | <asmodai> | every ff I have, 4, aurora, nightly, has -no-remote -P to the command line shortcut |
| 08:21 | <asmodai> | and I have 3 different profiles |
| 08:21 | <hsivonen> | asmodai: oh. If it doesn't work with different profiles for the two, it's worth filing a bug |
| 08:24 | <asmodai> | Double checking everything now, just to make sure I am not mistaken. |
| 08:25 | <MikeSmith> | what's cedar? |
| 08:25 | <asmodai> | A tree? |
| 08:26 | <hsivonen> | MikeSmith: do you mean in the Mozilla context? |
| 08:26 | <MikeSmith> | hsivonen: yeah |
| 08:27 | <MikeSmith> | just a branch name? |
| 08:27 | <hsivonen> | MikeSmith: it's technically a project branch, but it doesn't belong to any particular project |
| 08:27 | <MikeSmith> | ah, OK |
| 08:27 | <hsivonen> | MikeSmith: it's a place where people can land with less tree watching than in the mozilla-central case |
| 08:28 | <MikeSmith> | I see |
| 08:28 | <hsivonen> | MikeSmith: and then volkmar or ehsan merges it over from time to time (daily?) |
| 08:28 | <MikeSmith> | yeah, I saw some of those checkins and wondered |
| 08:34 | <MikeSmith> | hsivonen: btw, if you have a minute, could you please look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12400 |
| 08:34 | <MikeSmith> | it's a bug filed against the HTML5 facet of the W3C validator |
| 08:36 | <asmodai> | hsivonen: *sigh* Turns out that it had never created a subdir in my profiles directory for the profiles, but used the profiles dir itself. *sigh* Works as intended, pilot error, etc. |
| 08:40 | <hsivonen> | MikeSmith: surrounding a combining character in an element results in the page not being fully normalized, so the validator is working as designed |
| 08:41 | <hsivonen> | MikeSmith: if the goal is to have the base character and the combining mark render separately, making the combining mark combine with a U+0020 is the right thing to do |
| 08:41 | <MikeSmith> | OK |
| 08:41 | <hsivonen> | MikeSmith: if the goal is to have the combining mark combine with the base character but style the two parts differently, that's probably something that browsers shouldn't be required to support |
| 08:41 | <asmodai> | Interesting how the score on html5test.com is anti-aliased on ff and not on opera |
| 08:41 | <hsivonen> | asmodai: on Windows? |
| 08:41 | <asmodai> | aye |
| 08:42 | <hsivonen> | asmodai: different glyph renderer probably |
| 08:42 | <asmodai> | *nods* |
| 08:42 | <hsivonen> | Windows has many to choose from |
| 08:42 | <asmodai> | All the occurences of that specific font are AA on ff, and jagged on opera |
| 08:43 | <asmodai> | Just wonder why our dear friends at Opera would not enable/make use of it. |
| 11:25 | <karlcow> | http://www.w3.org/Conferences/WWW4/Papers/190/ |
| 11:25 | <karlcow> | Using versioning to support collaboration on the WWW |
| 12:32 | <zcorpan> | hsivonen: good catch about DOMContentLoaded |
| 12:33 | <zcorpan> | hsivonen: i don't see any reason not to |
| 12:34 | <hsivonen> | zcorpan: historically, defer scripts run between readyState becoming interactive and DOMContentLoaded firing |
| 12:34 | <hsivonen> | zcorpan: dunno if that matters for compat |
| 12:37 | <zcorpan> | aha. then it could be a compat problem i guess. although opera doesn't support defer scripts at all yet |
| 13:09 | <Workshiva> | karlcow: Based on the bibliography I'm going to guess it's from 1995 |
| 13:10 | <karlcow> | Worshiva, it is from 1995 indeed WWW4 http://en.wikipedia.org/wiki/World_Wide_Web_Conference |
| 13:11 | <karlcow> | document archeology :) |
| 13:11 | <karlcow> | danbri has made me curious about http://www.w3.org/History/1992/timbl-floppies/TimBerners-Lee_CERN/hype.tar.Z |
| 13:12 | <karlcow> | which contains "gems" too. |
| 13:14 | <karlcow> | there is a 1991 paper in ./hype/hypertext/Conferences/HT91/Paper/Paper.html with the title "An Alternative Architecture for Distributed Hypertext" |
| 13:17 | <danbri> | lots of fascinating stuff in there |
| 13:37 | <MikeSmith> | hsivonen: in the assertions code, when I encounter a tbody element, there's no way I can tell whether that tbody was inserted by the parser, right? |
| 13:38 | <Ms2ger> | They all were ;) |
| 14:16 | <MikeSmith> | Ms2ger: point taken |
| 14:18 | <MikeSmith> | so what I meant was, is that tbody one for which the parser did the 'act as if a start tag token with the tag name "tbody" had been seen' thing |
| 14:23 | <hsivonen> | MikeSmith: no way to find out |
| 14:23 | <hsivonen> | MikeSmith: why do you want to find out? |
| 14:23 | <MikeSmith> | hsivonen: OK, I figured |
| 14:23 | <MikeSmith> | hsivonen: for this case: |
| 14:29 | <hsivonen> | Ms2ger: the text about the expectation of http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1008 is the wrong way round, right? |
| 14:29 | <hsivonen> | Ms2ger: Chrome shows nothing in the frame fwiw |
| 14:30 | <Ms2ger> | hsivonen, yes, the tags should be shown |
| 14:30 | <Ms2ger> | Sorry for the confusion |
| 14:30 | <Ms2ger> | Chrome seems to just use its HTML path |
| 14:30 | <Ms2ger> | Try |
| 14:30 | <Ms2ger> | var vismap = "<b>test</b>"; |
| 14:31 | <hsivonen> | Ms2ger: cool. at least Firefox is in good company with the regression :-) |
| 14:31 | <Ms2ger> | Good? ;) |
| 14:44 | <MikeSmith> | hsivonen: sorry, meant to paste this: |
| 14:44 | <MikeSmith> | <table role="menu"><tr role="presentation"><td role="menuitem"></td></tr></table> |
| 14:45 | <MikeSmith> | in the context of whether the validator should report an error for that |
| 14:45 | <karlcow> | http://windowsteamblog.com/windows/b/windowssecurity/archive/2011/05/28/combating-social-engineering-tactics-like-cookiejacking-to-stay-safer-online.aspx |
| 14:46 | <MikeSmith> | hsivonen: but anyway, it seems to me it should be an error |
| 14:46 | <jgraham> | MikeSmith: ARIA conformance depends on whether implied elements were explicitly included or not? |
| 14:46 | jgraham | is not really following |
| 14:47 | <MikeSmith> | jgraham: i think it rightly depends on the DOM |
| 14:48 | <MikeSmith> | and because there's an implied tbody in that markup instance, and that tbody lacks an appropriate role, it's an error |
| 14:48 | <hsivonen> | MikeSmith: whether it should or not shouldn't depend on whether tbody was implied |
| 14:49 | <hsivonen> | MikeSmith: I guess that's an error then |
| 14:49 | <MikeSmith> | OK, I can see that |
| 14:51 | <jgraham> | MikeSmith: OK, as long as it depends on what gets into the final DOM, it all seems sane. |
| 15:01 | <AryehGregor> | Could we get rid of implementers⊙lwo? It only seems to be useful to people who are confused and think anyone actually uses it. |
| 15:01 | <hsivonen> | AryehGregor: it's good for confused people to get email responses |
| 15:02 | <AryehGregor> | As opposed to whatwg, where more than half a dozen people will actually read it? (Unless there are hordes of people who subscribed to implementers at some point and just don't post there?) |
| 15:04 | <hsivonen> | AryehGregor: well, in this case, I already replied to him in bugzilla and on Twitter |
| 15:05 | AryehGregor | should have read the bug he mentioned before responding |
| 17:21 | <gsnedders> | From Dojo: <iframe id="blah" name="blah" src="javascript:'<html><body><div id=subDiv></div></body></html>'"></iframe> |
| 17:27 | <jcranmer> | ,,,hello |
| 17:29 | <Ms2ger> | jcranmer, hi |
| 17:30 | <jcranmer> | sorry |
| 17:30 | <jcranmer> | that was lag in my IRC client |
| 17:30 | <jcranmer> | I thought I was in a different channel |
| 19:14 | <gavin__> | where can I see the "blame" for http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-external-addsearchprovider ? |
| 19:17 | <gavin> | hmm found http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2011/005298.html |
| 19:21 | <gavin> | Hixie: what's the reasoning behind the same-origin check for window.external.AddSearchProvider? |
| 20:01 | <Hixie> | gavin: it's what browsers do, iirc |
| 20:01 | <Hixie> | (from memory, could be wrong) |
| 20:02 | <gavin> | Hixie: firefox doesn't |
| 20:02 | <gavin> | (that's why I'm asking - wondering if there's reason for me to implement that) |
| 20:03 | <gavin> | maybe I can find a chromium bug about it |
| 20:04 | <gavin> | http://www.chromium.org/developers/design-documents/chromium-search-provider-js-support mentions the restriction but doesn't mention reasoning |
| 20:15 | <MikeSmith> | lord help us |
| 20:15 | <Ms2ger> | ... the CSSWG is approaching |
| 20:16 | <MikeSmith> | a sign of the End Times |
| 20:40 | <Hixie> | gavin: firefox didn't seem to implement the api very thoroughly so iirc i paid more attention to the other uas (IE, mainly) |
| 20:40 | <Hixie> | gavin: but it may also just have been something that seemed like a good idea at the time |
| 20:40 | <Hixie> | gavin: let me look closer |
| 20:40 | <gavin> | we implement if fully, though IsSearchProviderInstaller is just a stub |
| 20:40 | <Hixie> | gavin: pretty sure the origin check in step 4 there is an IE thing |
| 20:41 | <Hixie> | stub != fully :-P |
| 20:41 | <gavin> | ok ok :) |
| 20:42 | <Hixie> | i can't think of a security reason for not adding search engines from other sites off hand |
| 20:42 | <gavin> | is "scriptURL" in http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-external-addsearchprovider point 2 a typo? |
| 20:42 | <gavin> | seems like it should be either "url" or "engineURL" |
| 20:42 | <Hixie> | especially since the opensearch file contains the "real" search URL and opensearch lets you specify any random url |
| 20:43 | <gavin> | (to match non-normative box above, or interface definition) |
| 20:43 | <Hixie> | yeah step 2 is bogus |
| 20:43 | <Hixie> | let me fix this |
| 20:43 | <Hixie> | i'll fix step 2 and remove the check in step 4 |
| 20:43 | <gavin> | ok |
| 20:43 | <gavin> | that was easy! |
| 20:43 | <Hixie> | :-) |
| 20:44 | <Hixie> | i happened to not be editing anything else at the time :-) |
| 20:44 | <Hixie> | usually when i'm like "file a bug" it's because i'm in the middle of some other edit |
| 20:45 | <Hixie> | ok checked in |
| 20:46 | <gavin> | thanks! |
| 20:46 | <Hixie> | np |
| 20:46 | <Hixie> | ok let's see if i can finish off the websocket feedback |
| 20:59 | <AryehGregor> | I just found a case where execCommand() produces a non-serializable DOM in every browser in exactly the same way: formatBlock with argument <p> on <xmp>foo</xmp>. Produces <xmp><p>foo</p></xmp> in every browser. |
| 20:59 | <AryehGregor> | And in my algorithm, except I'm about to fix my algorithm. :) |
| 20:59 | <AryehGregor> | Oh, wait. |
| 20:59 | <AryehGregor> | Firefox fails differently: <p><xmp>foo</xmp></p>. |
| 20:59 | <AryehGregor> | Oh well. |
| 21:01 | AryehGregor | discovers a bug in Firefox's innerHTML serialization algorithm too: <xmp><</xmp> serializes to <xmp><</xmp>, so if you repeatedly serialize and unserialize you add arbitrarily many &'s |
| 21:02 | <The_8472> | < is not valid between tags |
| 21:02 | <The_8472> | it always has to be escaped |
| 21:03 | <AryehGregor> | The_8472, well, it's not *valid*, but in <xmp> it works. |
| 21:03 | <AryehGregor> | It's valid inside <script> or <style>. |
| 21:03 | <The_8472> | that's CDATA |
| 21:03 | <AryehGregor> | <xmp> behaves the same way as those. |
| 21:03 | <AryehGregor> | "CDATA" is not a term used by the HTML5 standard. |
| 21:03 | <AryehGregor> | But <xmp> parses the same as <script> or whatnot, its contents are made into one big text node until you hit a </xmp>. |
| 21:03 | <The_8472> | xmp is html5? |
| 21:03 | <The_8472> | i don't think so |
| 21:04 | <AryehGregor> | It's not valid, no, but the parsing behavior for it is defined. |
| 21:04 | <AryehGregor> | It's a legacy HTML feature that all browsers support. |
| 21:04 | <AryehGregor> | <plaintext> too, although that's more useless. |
| 21:04 | <The_8472> | my point is that argueing with the HTML5-parser for non-html5 data doesn't make sense |
| 21:05 | <AryehGregor> | Just because it's not conforming doesn't mean it doesn't have to be supported. |
| 21:05 | <The_8472> | since the parser specifically states *where* to switch its parsing mode, e.g. for script tags |
| 21:05 | <AryehGregor> | Also for xmp tags. |
| 21:05 | <AryehGregor> | Anyway, this is beside the point, it's a browser bug no matter what. |
| 21:06 | <The_8472> | can't find a single mention of "xmp" in the html5 spec |
| 21:07 | <The_8472> | oh, there |
| 21:07 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody |
| 21:07 | <AryehGregor> | Try it yourself, it works in all browsers. |
| 21:08 | <The_8472> | "Follow the generic raw text element parsing algorithm." mhh, i see |
| 21:31 | <jgraham> | BTW I would particually like feedback from webkit people on http://lists.w3.org/Archives/Public/public-html-testsuite/2011May/0007.html |
| 21:32 | <jgraham> | (well I want feedback from everyone, but Mozilla people already looked and asking Microsoft people on #whatwg seems like the definition of pointless) |
| 22:23 | <Hixie> | hsivonen: what criteria are you using to decide what rel="" values to allow? |
| 22:48 | <AryehGregor> | Interesting. Opera and WebKit support <pre align=right>, IE and Gecko don't. |
| 22:49 | <AryehGregor> | That seems bizarre. |
| 22:49 | <AryehGregor> | Maybe older IE supports it, and IE9 dropped support? |
| 22:49 | <AryehGregor> | (spec doesn't seem to mention it) |
| 22:51 | <AryehGregor> | Ugh, justify* are another case where there's no way to emulate the legacy HTML attributes' effect in CSS. |
| 22:51 | <AryehGregor> | <div align=right> is very different from <div style="text-align: right">. |
| 22:51 | <AryehGregor> | Also, in this case the CSS effect is much less useful . . . |
| 22:58 | <zewt> | ie guy on w3-webapps asking if he should be throwing UNKNOWN_ERR is so very ... IE |
| 23:51 | <The_8472> | <AryehGregor> Ugh, justify* are another case where there's no way to emulate the legacy HTML attributes' effect in CSS. <- margin-left:auto;margin-right:0px? |
| 23:52 | <The_8472> | although css needs width: shrink-to-fit; ... |