| 00:25 | <Hixie> | hober: ok, i started on http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129 |
| 00:36 | <AryehGregor> | Wow, it's really hard to select things exactly across multiple lines in IE9 beta (or maybe just on Windows generally?). |
| 00:37 | <Hixie> | yeah they do some annoying word-snapping thing |
| 00:39 | <AryehGregor> | Hixie, more tests: http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/selection-dir.html |
| 00:39 | <AryehGregor> | Notice that the two extra manual steps didn't actually catch any additional bugs, AFAICT. |
| 00:39 | <AryehGregor> | (I.e., no tests failed for tests 2 or 3 that I notice in any browser that didn't also fail for 1, although I didn't check carefully.) |
| 00:39 | <AryehGregor> | I'd like to leave it at that for now and move onto extend(). |
| 00:52 | <Hixie> | AryehGregor: i'm about to rush out the door, but will look tomorrow (ping me if i forget) |
| 00:52 | <AryehGregor> | k. |
| 00:52 | <AryehGregor> | How do I get hold of a node from a document other than the current one? |
| 00:53 | <Hixie> | iframe? |
| 00:53 | <AryehGregor> | I guess. |
| 00:53 | <Hixie> | hober: i filled in the bugs in http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129 ; i'll start looking at the details tomorrow. |
| 00:54 | <Hixie> | hober: i'm thinking for some of these we'll have to explicitly have separate sections for technical rationales and process rationales (a number of the bugs were just escalated without any attempt at conflict resolution; some were escalated without even saying what the bug was) |
| 00:54 | <Hixie> | right, outta here |
| 00:54 | <Hixie> | bbl |
| 01:15 | <AryehGregor> | So if a method's argument is defined as a Node, what happens if you pass something other than a Node? |
| 01:15 | AryehGregor | really needs to read WebIDL |
| 01:21 | <AryehGregor> | So Firefox often throws NS_SOMETHING_ERR for various errors. When standardizing, should I just pick a DOMException to throw instead? |
| 01:22 | <AryehGregor> | That seems to be the way all the specs are written, but I'm not sure. |
| 01:22 | <heycam> | AryehGregor, TypeError |
| 01:22 | <heycam> | that's what Web IDL says to throw |
| 01:23 | <AryehGregor> | Ah, okay. |
| 01:23 | <AryehGregor> | Makes sense. |
| 01:23 | <AryehGregor> | Although in this case, everyone throws a different type of exception and none of them are TypeErrors. |
| 01:23 | <heycam> | :) |
| 01:23 | <heycam> | I think TypeError is a reasonable choice for implementations to eventually converge on. |
| 01:24 | <AryehGregor> | What's TYPE_MISMATCH_ERR supposed to be used for, then? |
| 01:24 | <AryehGregor> | http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-TYPE_MISMATCH_ERR |
| 01:24 | <heycam> | I believe that's for the crazy schema stuff. |
| 01:25 | <AryehGregor> | Crazy schema stuff. |
| 01:25 | <AryehGregor> | Hmm. |
| 01:25 | <heycam> | oh it's not even thrown by dom 3 core |
| 01:25 | <AryehGregor> | Maybe I should go ahead and just read WebIDL and DOM Core all the way through before I start speccing anything here. |
| 01:25 | <heycam> | what method is this for? |
| 01:25 | <AryehGregor> | Selection.extend(). |
| 01:26 | <heycam> | (actually I'm probably wrong about that being for crazy schema stuff. that's VALIDATION_ERR, and perhaps others.) |
| 03:10 | <oojacoboo> | so, anyone from the chromium project here? |
| 03:10 | <oojacoboo> | what was up with that whole, we're dropping h.264 and going "open" crap all about? |
| 03:13 | <wirepair> | wouldn't #chromium be a better place to ask that? |
| 03:13 | <oojacoboo> | didnt' know that was a channel |
| 03:13 | <oojacoboo> | thanks |
| 03:13 | <wirepair> | :) |
| 03:22 | jwalden | reads http://dev.w3.org/csswg/css3-images/#sizing |
| 04:13 | <oojacoboo> | can someone clarify the <address> element for me? |
| 04:14 | <oojacoboo> | would it be appropriate for a physical address or other contact information on a contact us page? |
| 04:15 | <oojacoboo> | and if so, how is it intended to be used? |
| 04:15 | <oojacoboo> | the spec seems to be very vague on this element, just saying that it's used to refer to an <article> |
| 04:16 | <oojacoboo> | surely there is more purpose to that element than just <article>, the internet isn't only blogs |
| 04:17 | <jgv> | I believe the spec says "any related content". It is vague though |
| 04:17 | <oojacoboo> | "The address element represents the contact information for its nearest article or body element ancestor. If that is the body element, then the contact information applies to the document as a whole." |
| 04:18 | <oojacoboo> | it seems to me that this is just for linking to another site where information regarding a blog post was referenced, or whatever |
| 04:18 | <oojacoboo> | but that seems extremely short-sighted |
| 05:57 | <Hixie> | oojacoboo: <address> is for the contact information of the page (or section), typically the e-mail address of the page's author. |
| 06:12 | <hsivonen> | tagged #adobe: https://twitter.com/#!/ChromeBrowser/status/25317539470909440 |
| 06:35 | <othermaciej> | hsivonen: hmm, doesn't look like a parody twitter account |
| 07:38 | <hsivonen> | A TLA I was unaware of until a few seconds ago: http://en.wikipedia.org/wiki/XRX_%28web_application_architecture%29 |
| 07:38 | <hsivonen> | "The XRX architecture is also tightly coupled to W3C standards (CSS, XHTML 2.0, XPath, XML Schema) to ensure XRX applications will be robust in the future." |
| 07:50 | <MikeSmith> | hsivonen: nice use of the passive tense there |
| 07:50 | <MikeSmith> | "XRX is considered to have a clean and elegant design." |
| 07:51 | <zcorpan> | should we add overflow:hidden to img, video etc in the ua stylesheet? https://bugs.webkit.org/show_bug.cgi?id=52103 |
| 07:54 | <MikeSmith> | zcorpan: btw, thanks for heads-up about window.console for workers |
| 07:56 | <zcorpan> | hmm i imagine <style scoped>@font-face... is going to be a PITA to implement |
| 07:57 | hsivonen | is slighly amused at the appropriateness of XRX also being the stock ticker of Xerox considering that most often when I see Xerox participation at the W3C, it is related to XForms |
| 08:15 | <MikeSmith> | hsivonen: about the 0xFEFF check, I cargo-culted that in there based on what was in the existing IriRef.java code |
| 08:16 | <MikeSmith> | anyway, I will remove it |
| 08:17 | <MikeSmith> | it makes no sense in this context |
| 08:17 | <MikeSmith> | though after thinking about it, I now wonder why it's in the IriRef code |
| 08:17 | MikeSmith | reads some spec |
| 08:18 | <MikeSmith> | I guess the URL parsing algorithm requires it?] |
| 08:19 | <MikeSmith> | oh |
| 08:19 | <MikeSmith> | or the IRI spec does |
| 08:19 | <MikeSmith> | hmm |
| 08:19 | <hsivonen> | I wonder if the IRI spec matches reality there |
| 08:19 | <MikeSmith> | or not |
| 08:19 | <MikeSmith> | is it actually in the IRI spec/ |
| 08:19 | <MikeSmith> | ? |
| 08:19 | <hsivonen> | no idea |
| 08:20 | <MikeSmith> | I'm looking at the IRI spec now and I don't see it |
| 08:21 | <hsivonen> | time to look at hg blame, I guess |
| 08:21 | <MikeSmith> | yeah |
| 08:24 | <hsivonen> | I'm failing at using bitbucket's UI |
| 08:24 | <MikeSmith> | changeset: 250:7305f61e790d , summary: IRI changes, parametrize IANA lang tag registry URI |
| 08:24 | <hsivonen> | ah. the source tab works |
| 08:25 | <hsivonen> | MikeSmith: need to browse back in time from that one |
| 08:25 | <MikeSmith> | OK |
| 08:26 | <hsivonen> | https://bitbucket.org/validator/syntax/changeset/e1c4c6771cac |
| 08:26 | <hsivonen> | that's the right changeset |
| 08:26 | <asmodai> | hsivonen: Question, how can I best trace what is causing firefox to crash every single time when I close the program? |
| 08:27 | <hsivonen> | so clearly, back then I thought it's correct to swallow a BOM in javascript: URLs |
| 08:28 | <hsivonen> | asmodai: If this is on Windows and the crash reporter shows up, submitting the crash to Mozilla and then looking it up by the id shown in about:crashes is a good start |
| 08:28 | <hsivonen> | asmodai: or have you already gotten that far? |
| 08:29 | <asmodai> | hsivonen: sent in many crash reports, but hadn't thought of looking up the id |
| 08:29 | <asmodai> | about:crashes right? |
| 08:29 | <asmodai> | ah yes, loading the archive now |
| 08:30 | <hsivonen> | MikeSmith: found the reason! |
| 08:30 | <MikeSmith> | cool |
| 08:30 | <hsivonen> | MikeSmith: http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03#section-3.1 |
| 08:30 | <MikeSmith> | something in the JS spec? |
| 08:30 | MikeSmith | reads |
| 08:30 | <MikeSmith> | ah |
| 08:31 | <MikeSmith> | the scheme part |
| 08:31 | <asmodai> | hsivonen: http://crash-stats.mozilla.com/report/index/2fefc5de-89a4-4bb4-8d18-ee5e92110111 |
| 08:31 | <hsivonen> | MikeSmith: so looks like you don't need that bit of code for event handlers |
| 08:31 | <MikeSmith> | yeah |
| 08:31 | <MikeSmith> | thanks for doing the archaeology |
| 08:32 | <hsivonen> | MikeSmith: np. |
| 08:32 | <hsivonen> | MikeSmith: I have no idea how well Björn's draft reflects reality on this point, BTW |
| 08:33 | <MikeSmith> | well he musta had some reason for adding it least |
| 08:33 | <hsivonen> | asmodai: that's an interesting stack |
| 08:33 | <hsivonen> | asmodai: does it crash without add-ons |
| 08:33 | <zcorpan> | hsivonen: http://krijnhoetmer.nl/irc-logs/whatwg/20101224#l-219 |
| 08:34 | zcorpan | doesn't know what annevk is referring to there |
| 08:34 | <hsivonen> | asmodai: I'm suspecting an add-on that's violating thread-safety rules |
| 08:34 | <Hixie> | if anyone wants to help hober and i with http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129 please feel free |
| 08:34 | <asmodai> | hsivonen: Yeah, think I managed that too, but will retry that just to be sure. Number of open tabs shouldn't be an issue should it? |
| 08:35 | <hsivonen> | zcorpan: interesting. Thanks. |
| 08:35 | <hsivonen> | hmm. annevk is not on IRC! |
| 08:35 | <MikeSmith> | heh |
| 08:35 | <Hixie> | in particular, we need the rationales filling out for the other bugs (only the first bug has been started so far), and we need to study the other CP's proposed details to see if they're proposing anything other than what those bugs were proposing |
| 08:35 | <MikeSmith> | we need a tellbot |
| 08:35 | <Hixie> | in the meantime, i must sleep! :-) nn |
| 08:35 | <zcorpan> | MikeSmith: he reads teh logs |
| 08:36 | <hsivonen> | asmodai: hard to guess if the number of tabs is relevant |
| 08:39 | <asmodai> | hsivonen: but in general the number of tabs should not cause instability? :) |
| 08:39 | <hsivonen> | asmodai: not in general |
| 08:40 | <asmodai> | ok, now to test some |
| 08:44 | <hsivonen> | asmodai: I'm failing to see the number of your CPU cores. |
| 08:45 | hsivonen | was pretty sure the crash stat tool was supposed to show the # of cores somewhere |
| 08:49 | <asmodai> | should be 2 cores |
| 08:49 | <asmodai> | core 2 duo @ 2.8 GHz |
| 08:49 | <hsivonen> | asmodai: OK. those extension thread-safety crashes are more common with more than one core |
| 08:50 | <asmodai> | hsivonen: so in essence, if I would set firefox to affinity to cpu 0 I would expect most of these crashes to be gone suddenly? |
| 08:50 | <hsivonen> | asmodai: anyway, I really have *no* clue about what's causing your crash :-( |
| 08:50 | <asmodai> | hehehe |
| 08:50 | <hsivonen> | asmodai: possibly |
| 08:50 | <asmodai> | I need to check some of the other crash ids, see if they're similar |
| 08:55 | <asmodai> | hsivonen: looks like one crash I reported was fixed: http://crash-stats.mozilla.com/report/index/bp-6fad02db-0441-4439-bd17-1dced2110111 |
| 08:55 | <asmodai> | oh wait, that's from the 4.0beta >_< |
| 08:56 | <asmodai> | these are the similar crashes: |
| 08:56 | <asmodai> | http://crash-stats.mozilla.com/report/index/26cdfc0e-8017-42ae-b987-0b8e92110111 |
| 08:56 | <asmodai> | http://crash-stats.mozilla.com/report/index/7dbcbe57-79f6-45a6-bc54-c31712110110 |
| 08:56 | <asmodai> | http://crash-stats.mozilla.com/report/index/89ddd516-1055-487f-8ba8-f489f2110110 |
| 09:02 | <MikeSmith> | hsivonen: very quick question: in the code I added for checking values of event-handler attributes, I have it do compileReader(reader, null, -1, null) -- with -1 for the line-number value |
| 09:03 | <MikeSmith> | that has the effect of suppressing the "(unnamed script#1)" part that would otherwise be appended to each error message |
| 09:03 | <MikeSmith> | which seems not to be of any use in practice in identify the actual location of the error |
| 09:03 | <MikeSmith> | OK if I make that same change in the IriRef.java code? |
| 09:03 | <hsivonen> | MikeSmith: OK |
| 09:03 | <MikeSmith> | thanks |
| 09:04 | <hsivonen> | CLASSPATH is still the #1 least pleasant thing about Java |
| 09:06 | <MikeSmith> | hsivonen: there's a lot to choose from… |
| 09:07 | <hsivonen> | one day Jython respects my CLASSPATH but not today... |
| 09:08 | <hsivonen> | worked on Friday... |
| 09:09 | <hsivonen> | typos... |
| 09:31 | <annevk> | IRC called? |
| 09:32 | <annevk> | The problem with the current javascript URL draft is that it does not deal with encoding. Apparently browsers do quite a few different things. |
| 09:33 | <hsivonen> | annevk: what about the UTF-8 BOM bit? |
| 09:34 | <asmodai> | lol |
| 09:35 | <annevk> | hsivonen, not sure |
| 09:35 | <annevk> | hsivonen, othermaciej, that ChromeBrowser twitter account is not an official one |
| 09:36 | <hsivonen> | annevk: not official as in not run by the PR dept or not official as in not run by people on the Chrome team? |
| 09:36 | <paul_irish> | both. |
| 09:37 | <hsivonen> | paul_irish: I see |
| 09:37 | <annevk> | hsivonen, it says it is not affiliated with Google and does not like to Google announcements but to some other site |
| 09:37 | <annevk> | s/like/link/ doh |
| 09:37 | <hsivonen> | is there an official twitter account? |
| 09:37 | <paul_irish> | there are a few... |
| 09:38 | <paul_irish> | @chromiumdev is mananged by humans... the devrel team. it's for web developers... @googlechrome is from marketing.. very end-user-y |
| 09:39 | <paul_irish> | and then @chromiumbrowser is just blog.chromium.org and @googlechromedev is just the chrome releases blog |
| 09:39 | <annevk> | @chromiumbrowser follows @chromebrowser though |
| 09:40 | <hsivonen> | paul_irish: thanks |
| 09:40 | <_mthz> | Anyone know why the attribute value double quoted and attribute value unquoted tokenizer states both have U+0000 NULL handling, but the single quoted state does not? |
| 09:40 | <hsivonen> | annevk: that's probably how I ended up following @chromebrowser |
| 09:40 | <paul_irish> | gross. i'll see if i can fix that, annevk |
| 09:40 | <_mthz> | seems like a bug, no? |
| 09:41 | <hsivonen> | stuff I learned today: createElement (without NS) in OpenJDK's default DOM impl. creates element nodes with localName set to null |
| 09:41 | <hsivonen> | FAIL |
| 09:41 | <annevk> | _mthz, sounds like it... |
| 09:42 | <annevk> | _mthz, unquoted is handled though |
| 09:42 | <_mthz> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11262 |
| 09:42 | <annevk> | _mthz, in complete section 12.2.4.40 handles U+0000 |
| 09:42 | <_mthz> | yeah, double and unquoted handle U+0000, but single quoted doesn't. Hixie responded there with "oops", so sounds like it's a bug =) |
| 09:43 | <_mthz> | what's that refer to? |
| 09:43 | annevk | misread |
| 09:43 | <annevk> | that was http://whatwg.org/C#attribute-value-(unquoted)-state |
| 09:44 | <_mthz> | Right, but this doesn't: http://www.whatwg.org/specs/web-apps/current-work/complete/tokenization.html#attribute-value-%28single-quoted%29-state |
| 09:46 | <annevk> | yeah I know now :) |
| 09:46 | <_mthz> | gotcha =) |
| 09:47 | <MikeSmith> | kennyluck: https://bugs.webkit.org/show_bug.cgi?id=52359 |
| 09:59 | <hsivonen> | annevk: what was the element I should use instead of atom:updated when my system can't distinguish between meaningful updates and typo edits? |
| 10:00 | <hsivonen> | annevk: AFAICT, updated and published are the only two date elements that Atom has |
| 10:01 | <hsivonen> | and published would be even less appropriate for me |
| 10:03 | <annevk> | hsivonen, atom:updated I think |
| 10:03 | <hsivonen> | annevk: ah, ok. I thought you said earlier that I should have used something else |
| 10:04 | <annevk> | hmm, atom:modified? |
| 10:04 | <hsivonen> | annevk: doesn't exist in the spec |
| 10:04 | <annevk> | I guess that was an older thing then |
| 10:05 | <annevk> | atom:created existed as well at one point |
| 10:05 | <annevk> | ooh, hmm, http://tools.ietf.org/html/rfc4287#section-4.2.15 |
| 10:05 | <annevk> | it seems you should not change atom:updated unless it was significant |
| 10:06 | <annevk> | I think I store published/updated/modified therefore in my blog software, but I'm not sure why |
| 10:06 | <hsivonen> | annevk: well, I use the file system modification date |
| 10:06 | <annevk> | well, it would be interesting, if I actually stored the changes |
| 10:06 | <hsivonen> | annevk: my system doesn't store anything else |
| 10:07 | <hsivonen> | annevk: and my manually-maintained human-readable update dates have precision only to the day |
| 10:07 | <annevk> | isn't that gonna fail if you need to change something about the files? or move them somewhere else? |
| 10:07 | <annevk> | seems kind of tricky |
| 10:07 | <annevk> | but also neat, in a way |
| 10:08 | <hsivonen> | annevk: yeah, in 2005 I lost all modification dates on my site |
| 10:08 | <hsivonen> | I'm still mildly bitter about that incident |
| 10:09 | <hsivonen> | hmm. so did we indeed end up defining Atom dates by reference to XSD? FAIL. |
| 10:10 | <hsivonen> | hmm. no |
| 10:10 | <hsivonen> | so Atom wants to have time in addition to date |
| 10:10 | <annevk> | oh yeah, there was that whole scheme discussion and whether it should be another RDF vocabulary |
| 10:10 | <annevk> | oh god |
| 10:11 | <hsivonen> | I guess I could fake the time |
| 10:11 | <annevk> | such a mess |
| 10:11 | <hsivonen> | bah. I'm just going to stick this into cron and let it run for another 5 years |
| 10:11 | <annevk> | it actually demands time? |
| 10:11 | <hsivonen> | annevk: year |
| 10:12 | <hsivonen> | annevk: must match date-time production in RFC 3339 |
| 10:12 | <hsivonen> | s/year/yeah/ |
| 10:12 | <annevk> | silly |
| 10:13 | <annevk> | I have actually been wondering about removing precision from the datetime fields in my database |
| 10:17 | <annevk> | hsivonen, link to the Media Foundation decoder? |
| 10:19 | <hsivonen> | annevk: http://code.google.com/p/webm/issues/detail?id=201 |
| 10:24 | <annevk> | ''The Catholic Church shut down Galileo for a hundred years. I think we can shut down Julian Assange.'' o_O |
| 10:24 | <annevk> | via @wikileaks |
| 10:27 | <jgraham> | Erm, well the first sentence is untrue, at least |
| 10:30 | <annevk> | and Gruber flamed WebM some more |
| 10:30 | <annevk> | wtf |
| 10:31 | <hsivonen> | annevk: where? |
| 10:32 | <annevk> | blog last night I guess |
| 10:32 | <annevk> | oh, and on twitter |
| 10:34 | <hsivonen> | I wonder if Gruber still remembers RealVideo. |
| 10:34 | <Rik`> | btw, is my calculation ok? https://twitter.com/rik24d/status/25469886570438656 |
| 10:37 | <annevk> | Rik`, I think it was something in that order, yes |
| 10:38 | <annevk> | at least, last I heard |
| 11:29 | <gsnedders> | Apparently (this is coming via others) no browser fires storage events on the Document that did the mutation of localStorage. |
| 11:32 | <gsnedders> | e.g., http://software.hixie.ch/utilities/js/live-dom-viewer/saved/777 |
| 11:45 | <Evet> | jsonp is good only for public data, right? |
| 11:46 | <hsivonen> | Evet: correct |
| 11:47 | <hsivonen> | (well, maybe the Sec-Origin header is going to change that) |
| 11:49 | <Evet> | so, iframe is the only solution to put user's private data into cross-domain widgets? |
| 11:50 | <hsivonen> | Evet: it's a safe way at least |
| 11:51 | <gsnedders> | Apparently IE9 fires on the doucment doing the mutation of the localStorage object |
| 11:51 | <hsivonen> | so how does one browse Maven repositiories using a Web browser? |
| 11:53 | <hsivonen> | http://www.mvnbrowser.com/index.html maybe? |
| 11:54 | <Evet> | hsivonen: is it really impossible to steal the content of an iframe? |
| 11:56 | <hsivonen> | Evet: if you find a way to steal the content of a different-origin iframe, you should file browser security bugs |
| 11:58 | <Evet> | sure |
| 12:04 | <annevk> | I wish the other public-html-xml participants were a bit more pro-active with simply experimenting how an HTML5 parser works |
| 12:04 | <annevk> | it's not like it's rocket science |
| 12:08 | <Ms2ger> | The HTML5 parser? It certainly looks like rocket science :) |
| 12:09 | <annevk> | Maybe I should start building rockets then |
| 12:17 | <Philip`> | Rocket science usually suffers from draconian error handling |
| 12:30 | <Evet> | hsivonen: should i render private content as image file from my server? |
| 12:32 | <hsivonen> | Evet: That's an inaccessible solution if the alternative is serving text in an iframe |
| 12:32 | <hsivonen> | Evet: so no |
| 12:33 | <hsivonen> | Evet: unless the private data is visual to begin with |
| 12:55 | <david_carlisle> | annevk: yes:-) (also I'm still confused by the split between people who are and are not on the TF) |
| 12:56 | <david_carlisle> | Although perhaps they have experimented but don't believe their results at just how weird it is? |
| 12:56 | <annevk> | I know someone who makes his own firework. Maybe I can ask him for advice :) |
| 12:57 | <annevk> | Oh wait, you meant the other thing... |
| 12:59 | <david_carlisle> | hsivonen: I think John's comments re having to quote xml in script were for the x(ht)ml serialisation |
| 13:00 | <hsivonen> | david_carlisle: oh. well, <script> and <style> are both normal in XML |
| 13:00 | <annevk> | can you say "Only non-commercial use is waived." ? |
| 13:01 | <hsivonen> | annevk: probably not. what does it mean to waive use? |
| 13:01 | <david_carlisle> | hsivonen: yes (at least I think that's what he meant) |
| 13:01 | <hsivonen> | annevk: you can waive an obligation |
| 13:02 | <annevk> | ah |
| 13:02 | <annevk> | "Only for non-commercial use the fee is waived." ? |
| 13:02 | <hsivonen> | annevk: in case you are writing about H.264, that's not exactly right. |
| 13:03 | <hsivonen> | annevk: in case you are writing about something else, the sentence makes sense. |
| 13:07 | <hsivonen> | annevk: actually, the sentence is semi-Yoda-ish like that |
| 13:09 | <annevk> | Yoda! |
| 13:09 | <annevk> | I rewrote it altogether, thanks |
| 13:10 | <hsivonen> | Lachy: blog.whatwg.org needs a WordPress update. |
| 13:11 | <Lachy> | hsivonen, ok |
| 13:13 | <Lachy> | huh, that's weird. I thought I did that update a couple of weeks ago. |
| 13:13 | <Lachy> | But looks like I only updated my own blog and forgot whatwg blog. |
| 13:16 | <hsivonen> | a new post on the WHATWG blog!111!11 |
| 13:17 | <hsivonen> | http://blog.whatwg.org/vnu-parser-1_3 |
| 13:17 | <Lachy> | hsivonen, you have admint rights on the blog, don't you? |
| 13:18 | <Lachy> | feel free to just click that update button to do it automatically next time you see it. It doesn't take any effort |
| 13:20 | <hsivonen> | Lachy: I figured that if I trigger the update and it breaks, I have no way to fix it. |
| 13:20 | <hsivonen> | Lachy: but ok. |
| 13:21 | <hsivonen> | Lachy: thanks |
| 13:22 | <annevk> | should I tweet on the WHATWG account? |
| 13:22 | <annevk> | or maybe retweet something? |
| 13:23 | <Lachy> | if anything breaks, then just ping me. |
| 13:23 | <Lachy> | annevk, no reason not to tweet on the whatwg account |
| 13:23 | <annevk> | I had a plan to integrate a twitterbot in the blog but not done yet |
| 13:23 | <annevk> | Lachy, yeah, just wondering if hsivonen already had a tweet on his personal account that I could then retweet from there |
| 13:23 | <annevk> | no need for duplicates :) |
| 13:24 | <Lachy> | oh |
| 13:27 | <hsivonen> | annevk: feel free to tweet (or retweet my tweet) |
| 13:31 | <annevk> | made a new one as yours does not link to blog.whatwg.org |
| 13:32 | <hsivonen> | annevk: ok |
| 13:33 | <matjas> | hsivonen: so the online version at http://html5.validator.nu/ is updated as well? |
| 13:34 | <hsivonen> | matjas: yes |
| 13:34 | <matjas> | it still errors for documents without a <title>, shouldn’t that be a warning? |
| 13:34 | <hsivonen> | matjas: that's not a parser thing |
| 13:35 | <hsivonen> | matjas: I'm not sure what the spec says about <title> today |
| 13:36 | <matjas> | http://i.imgur.com/MWDO5.png looks a bit contradictory |
| 13:38 | <hsivonen> | matjas: is your doc in srcdoc or wrapped in an email? |
| 13:39 | <matjas> | no way for the validator to know |
| 13:39 | <matjas> | it says “error” but then it goes on to say that there is in fact a case where it could be valid |
| 13:39 | <annevk> | well srcdoc it knows |
| 13:40 | <annevk> | because it would have to be in srcdoc :) |
| 13:40 | <matjas> | yah |
| 13:40 | <annevk> | and if it's over HTTP it knows too |
| 13:40 | <matjas> | well let’s assume it’s an email :) |
| 13:40 | <annevk> | maybe for local file upload it could give a slightly different indictor |
| 13:40 | <matjas> | <!DOCTYPE html><p>foo |
| 13:40 | <matjas> | i just used text input |
| 13:41 | <Ms2ger> | I think it's more useful to assume it's not an email |
| 13:41 | <annevk> | yeah |
| 13:41 | <matjas> | I agree; just saying that the error message is slightly confusing |
| 13:45 | <matjas> | (IMHO) |
| 13:45 | <zcorpan> | hmm, afaict when the document is a srcdoc document or an email, the spec allows multiple <title>s |
| 13:46 | <zcorpan> | oh, "There must be no more than one title element per document." |
| 13:47 | <Ms2ger> | Does Opera really support document.createElement("image")? |
| 13:47 | <zcorpan> | yep |
| 13:48 | <Ms2ger> | Why? |
| 13:48 | <zcorpan> | because image->img magic was implemented in a different layer than what the html5 spec says |
| 13:48 | <annevk> | also "supported" in XHTML |
| 14:35 | <annevk> | anyone care to quickly scan a blog post on h264 before I throw it online? |
| 14:55 | <zcorpan> | annevk: sure (not that i'm a specialist on h264 but anyway) |
| 14:56 | <annevk> | pm'd you a link |
| 15:03 | <Rik`> | annevk: I can if you still need it |
| 15:04 | <annevk> | please |
| 15:10 | <annevk> | http://www.flickr.com/photos/24374884@N08/5351656030/ |
| 15:10 | <annevk> | gotta love brucel |
| 15:32 | <foolip> | annevk, hit me with some blog post drafts! |
| 15:58 | <annevk> | done |
| 16:19 | <cszabo1> | Philip`: ping |
| 16:19 | <Philip`> | cszabo1: pong |
| 16:19 | <annevk> | also published now |
| 16:19 | <annevk> | http://annevankesteren.nl/2011/01/why-webm |
| 16:20 | <annevk> | first post this year, yay |
| 16:20 | <cszabo1> | Philip`: Did you have any time to consider my test proposal and the language change for the canvas drawing model? (The one related to shadow rendering.) |
| 16:23 | <Philip`> | cszabo1: I haven't looked at it since we last discussed it |
| 16:26 | <cszabo1> | Philip`, given that I do not thing the spec will change in a major way since most browsers support it in its current form, I would like to start to bring WebKit in compliance. This shadow issue though, I think it should be still fixed despite the fact that no browser does it correctly now. What do you think? |
| 16:27 | <cszabo1> | thing=think. |
| 16:35 | <Philip`> | cszabo1: Do you have a link to your spec proposal? |
| 16:36 | <cszabo1> | Philip`, It's in the mailing list archive here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029658.html |
| 16:38 | <cszabo1> | Philip`, I also have an example test that checks for what I think is correct behavior here: http://waplabdc.nokia-boston.com/browser/users/caszabo/shadow/index.htm |
| 16:43 | <Hixie> | hsivonen: so has public-html-xml worked out what problem it's trying to solve yet? |
| 16:44 | <Philip`> | http://canvex.lazyilluminati.com/misc/shadow/shadow2.html shows the current browser's shadow compositing behaviour in the first column, and the current spec in the second |
| 16:44 | <Philip`> | (Ignore the third column, it's not interesting) |
| 16:44 | <Philip`> | http://canvex.lazyilluminati.com/misc/shadow/shadow2c.html shows it with the suggested change to the spec in column two, I think |
| 16:45 | <Philip`> | See e.g. the second line of images, where a solid red shape is drawn with globalAlpha=0.5 |
| 16:46 | <Philip`> | With the current spec the shadow is visible behind the shape; the suggested change it's only visible outside the shape, because the shape and shadow get composited together before any globalAlpha is applied |
| 16:46 | <Ms2ger> | Hixie, I'm assuming "HTML" |
| 16:46 | <Philip`> | (This is all with the default source-over) |
| 16:47 | <Philip`> | Is that expected/unexpected good/bad behaviour? |
| 16:48 | <cszabo1> | Philip`, For source over my change proposal has no effect. The behavior should not change. |
| 16:49 | <cszabo1> | Philip`, My change is important for cases like copy, composite operation which will never show a shadow based on how the spec is currently worded. |
| 16:49 | <Philip`> | cszabo1: My interpretation is that it does affect source-over |
| 16:51 | <Philip`> | With the change the output is '(shape over shadow)*globalAlpha over canvas', instead of 'shape*globalAlpha over (shadow*globalAlpha over canvas)', so it's different, I think |
| 16:53 | <Hixie> | Ms2ger: from the list, it looks like the problem is "we don't understand the web", but i'm assuming that's not the actual problem |
| 16:53 | <Hixie> | Ms2ger: they said last month their first order of business was to state their problem |
| 16:53 | <Hixie> | Ms2ger: and they've had a month, so presumably they've done their first order of business |
| 16:54 | <Ms2ger> | Well, I thought WebSockets would be finished by now, too :) |
| 16:54 | <Hixie> | it basically was, before the ietf got involved |
| 16:55 | Ms2ger | likes hsivonen's reply about XForms |
| 16:55 | <cszabo1> | Philip`, It may be different in that some of the shadow may show under the shape, where as previously the previous content would. I think this is non-essential. I like the global alpha being applied to shape + shadow as a unit, but if this is not OK then probably my other idea that an exclusion like operator such as copy or source-in should not delete the shadow is not OK either. |
| 16:57 | <Philip`> | cszabo1: It's different in that the shadow *won't* show under solidly-coloured parts of the shape, regardless of globalAlpha, whereas previously it would if globalAlpha < 1, with source-over |
| 16:58 | <cszabo1> | Philip`, I tried to say the same thing. |
| 17:00 | <Philip`> | I don't know if it's necessarily problematic, but it's a visible change in more cases than just the rare copy+shadows case, so I guess we'd need to be more careful about incompatibilities |
| 17:00 | <Hixie> | Ms2ger: man, he didn't beat around the bush, huh |
| 17:00 | <cszabo1> | Philip`, Thinking about it, the debate comes down to as whether one thinks of the object and its shadow being one thing rendered in abstract and then composited in the scene or as two separate object individually rendered and composited. |
| 17:00 | <Hixie> | that's a better answer than any i could have given |
| 17:06 | <Philip`> | cszabo1: I don't have any particular opinion on what behaviour makes logical sense - I think the current spec is just based on reverse-engineering Safari several years ago, and mostly I care about there being interoperability, so the question is whether there are practical benefits that are worth the cost of getting ~5 implementors to agree and implement something different |
| 17:06 | <cszabo1> | Philip`, I am more of an engineer then a manager. I would like things to make sense. I feel that considering the object and its shadow as one (since they are rendered via one primitive) is what makes more sense. It is in line with the fact that a complex path, it is all rendered as one (regardless of the number of subpaths it is made of). |
| 17:07 | <Philip`> | Keep this channel's /topic in mind :-) |
| 17:08 | <cszabo1> | Philip`, Sorry, I forgot the thing about logic sorry. |
| 17:08 | <cszabo1> | I have to leave urgently. Sorry. |
| 17:14 | <annevk> | giving the Web Socket protocol to the IETF did not really turn out that well |
| 17:15 | <annevk> | although there are some people that seem to think it is for the better |
| 17:23 | <MikeSmith> | hsivonen: to use the JS version of the validator.nu HTML parser outside of the context of the http://livedom.validator.nu/ Web UI, is there an entry point I can use? |
| 17:45 | <rubys> | annevk: ping? |
| 17:48 | <annevk> | hey rubys |
| 17:48 | <rubys> | I've started to port xml5 to js... |
| 17:48 | <annevk> | :) |
| 17:48 | <rubys> | the bulk of the code is in the tokenizer, to which I made two sets of changes to the python version |
| 17:48 | <TabAtkins> | Heh, cool. |
| 17:48 | <rubys> | https://github.com/rubys/xml5/commit/9cc282495f76f92ba7a13ea34323d12399662b75 |
| 17:49 | <rubys> | the first is not substantive: since the code is so consistently formatted, i wrote a script to do the conversion. |
| 17:49 | <rubys> | there were a few minor cases where the indentation and continuations were not consistent, so I changed the input |
| 17:49 | <rubys> | (I use the continuation character to *not* emit a semi-colon, for example) |
| 17:49 | <annevk> | I see |
| 17:50 | <rubys> | the second is kinda substantive: |
| 17:50 | <rubys> | https://github.com/rubys/xml5/commit/67bf795953aee748fa140d53dd47e35226360e3b |
| 17:50 | <rubys> | the tokenizer was emitting one character at a time. html5 doesn't do it this way, and fixing this doesn't break the test cases. |
| 17:51 | <annevk> | I wonder if I have enough tests, but it looks fine |
| 17:51 | <rubys> | feel free to write more tests :-) |
| 17:51 | <annevk> | do you want access to code.google.com/p/xml5 ? |
| 17:52 | <rubys> | that would be cool... I would like to keep the versions in sync. |
| 17:53 | <annevk> | added you as committer |
| 17:53 | <rubys> | thanks! |
| 17:54 | <hober> | rubys: html5's tokenizer *does* emit one character at a time |
| 17:54 | <hober> | in the spec |
| 17:55 | <annevk> | I think he meant html5lib |
| 17:55 | <hober> | ahh, fair enough then. |
| 18:00 | <rubys> | any reason for the spec to emit one character at a time? |
| 18:00 | <Philip`> | Simplicity |
| 18:02 | <rubys> | oooo....kkkk.. In a spec that big, I don't think that difference takes it from "hugely complex and unintelligible" to "elegant simplicity", but... whatever :-) |
| 18:04 | <Philip`> | I'm not saying it does, I'm just saying it's simpler for the spec to deal with individual characters instead of trying to lump them together as a performance optimisation |
| 18:06 | <Philip`> | and describing performance optimisations is not a goal of the spec |
| 18:07 | <rubys> | Independent of performance, my mental model of what a 'token' is and html5's aren't in sync. |
| 18:07 | <rubys> | <averylongname value=averylongvalue>some text</averylongname> |
| 18:08 | <rubys> | 3 tokens? 11 tokens? |
| 18:10 | <Ms2ger> | A score |
| 18:11 | <Philip`> | If it was 3 then you couldn't incrementally render a long text node without violating the spec (because the spec wouldn't let you put half a text token into a text node in the DOM) |
| 18:12 | <Philip`> | unless the spec explicitly said you're allowed to split text tokens at certain points |
| 18:12 | <Philip`> | which would just be more complexity |
| 18:13 | <rubys> | can't that argument be played back in the other direction: if the number of tokens is a hard requirement, then performance optimizations are disallowed? |
| 18:13 | <annevk> | 11 tokens per HTML5, 2 nodes |
| 18:13 | <annevk> | 1 element |
| 18:14 | <TabAtkins> | Tokens aren't visible to the user, right? You can optimize those away as you wish. |
| 18:14 | <annevk> | rubys, only if you can observe the difference |
| 18:14 | <Philip`> | The number of tokens is not observable |
| 18:15 | <rubys> | Philip`: exactly. So your most recent argument is not relevant. |
| 18:15 | <Ms2ger> | s/your most recent/this/ |
| 18:16 | <rubys> | Interestingly enough (and a natural fallout of the design of node.js) is that with this change, the token will be split on network packet boundaries. |
| 18:16 | <Philip`> | You can run a script in a timer that looks at a half-parsed DOM, and if that script observes a DOM that cannot possibly be produced by a precise implementation of the spec (e.g. because it contains half a token which the spec says is indivisible) then the browser is non-conforming |
| 18:17 | <Philip`> | If the spec says to use individual characters, and the browser happens to batch them into packet-sized tokens, then the observed DOM will still always be one that could be produced by the spec |
| 18:18 | <Philip`> | (There will be some DOMs that the spec could produce which you'll never observe due to the batching, but that doesn't matter) |
| 18:20 | <cszabo1> | Philip`, Hi I'm back. I understand your concern about changing the behavior of source-over in my proposed change, but what do you think? Would you like the spec changed in the way I propose or not? |
| 18:23 | <Philip`> | cszabo1: I think your suggestion makes sense, but I don't personally care much about it making sense :-) |
| 18:24 | <cszabo1> | Philip`, As I view it that's progress for me, what do you care about? Or do you care about anything related to this aspect of the spec? |
| 18:25 | <dglazkov> | annevk++ |
| 18:27 | <Philip`> | cszabo1: Mostly I just want interoperability between browsers (else nobody will be able to use the feature at all, and it won't matter if half the browsers implement a better version of it) |
| 18:30 | <cszabo1> | A worthy goal. I admit. The question is how do you bring browsers together? I think that making things easy to implement on many platforms is one of the important factors. |
| 18:33 | <Philip`> | cszabo1: By some combination of writing things in the spec and expecting browsers to implement it, and updating the spec to match what browsers want to implement |
| 18:37 | <Philip`> | It seems like the path of least resistance at the moment is for browsers to implement the spec, because some have done so already (so it must be possible, and they might be resistant to rewriting their code) and there isn't agreement between them on preferring a different behaviour |
| 18:39 | <Philip`> | If you want different behaviour then probably the best approach is to talk to other browser developers and get them to agree the new behaviour is preferable and say they're willing to change their implementations to do that |
| 18:44 | <GPHemsley> | hsivonen: Do the validator changes apply to the website, or were those changes always implemented as they happened? |
| 18:56 | <AryehGregor> | Hixie, okay, I think I'm going to go read DOM Core and WebIDL before I do further work. Those seem to come up a lot, I think they're probably necessary for me to write a reasonable spec. |
| 18:57 | <AryehGregor> | (I mean, reading them will be the next work I do, as part of speccing extends(), before I get back to writing actual spec text.) |
| 18:58 | <annevk> | let me know if you have any comments on http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html |
| 18:58 | <AryehGregor> | Is that the one I should be reading, not DOM Core 3? |
| 18:58 | <AryehGregor> | "Obsoleting DOM Level 3 Core is not a goal. It is a fine specification for Java servers. Web DOM Core presents an alternative." |
| 18:58 | <AryehGregor> | I guess that suggests yes. :) |
| 19:00 | <Ms2ger> | annevk, how about you push my changes? ;) |
| 19:01 | <AryehGregor> | Looks like I should read WebIDL first, since that's a dependency. |
| 19:01 | <annevk> | yeah, makes sense |
| 19:03 | <annevk> | Ms2ger, done |
| 19:03 | <Ms2ger> | Yay :) |
| 19:08 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception should we nuke the <ol> or use <li value=25>? |
| 19:09 | <TabAtkins> | The latter. |
| 19:10 | <Ms2ger> | Oh right, forgot to make it ul's |
| 19:28 | <Hixie> | AryehGregor: seems reasonable! |
| 19:29 | <Hixie> | AryehGregor: i'll start reviewing those tests you mentioned when i get to work |
| 19:29 | <AryehGregor> | Hixie, k. |
| 19:43 | <AryehGregor> | Blech, WebIDL specifies out-of-range values should wrap instead of clamping. Is that really needed for web compat? |
| 19:44 | <Ms2ger> | WebKit did that for select.add iirc |
| 19:44 | <jamesr_> | AryehGregor: it's pretty retarded and iirc we don't do that currently for things in canvas |
| 19:44 | <jamesr_> | i'd really like to know why it says that |
| 19:45 | <annevk> | heycam, ^^ |
| 19:45 | AryehGregor | only just figured out that heycam is Cameron McCormack |
| 19:46 | <annevk> | fwiw, WebIDL has a Bugzilla component just like HTML5 |
| 19:46 | <AryehGregor> | I know. |
| 19:46 | <AryehGregor> | I'm keeping the "New Bug" form open in a tab to accumulate typo fixes. |
| 19:48 | <heycam> | AryehGregor, that might change, yeah |
| 19:48 | <heycam> | AryehGregor, yeah please file a bug |
| 19:48 | <AryehGregor> | k. |
| 19:49 | <heycam> | for canvas it's bad to wrap, as someone (bz?) pointed out, since you can easily go to completely different colours with a small value change |
| 19:49 | <heycam> | there are some built-in things in the ES spec that do wrap |
| 19:49 | <heycam> | (whenever there's a ToUint32, for example) |
| 19:51 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11749 |
| 19:51 | <heycam> | thanks! |
| 20:12 | <foolip_> | gsnedders, yt? |
| 20:13 | <gsnedders> | foolip_: yeah |
| 20:13 | <foolip_> | is http://gsnedders.html5.org/outliner/ the outliner used by anolis? |
| 20:13 | <gsnedders> | foolip_: Well, it's an old fork of it |
| 20:13 | <foolip_> | and is the code for that process.py available and easy for me to reuse? |
| 20:14 | <gsnedders> | I keep meaning on publishing the code :P |
| 20:14 | <foolip_> | does it just figure out the section headings, or does it also find which nodes belong to which section? |
| 20:15 | <gsnedders> | Just the former, AFAIK |
| 20:15 | <foolip_> | in any case, do you have the code so I can see if I could reuse some? |
| 20:15 | <gsnedders> | I started hacking it once to do both |
| 20:16 | <foolip_> | by email would be fine if you don't want to clean it up for the world to see :) |
| 20:16 | <gsnedders> | http://hg.gsnedders.com/anolis2/file/0ae85731c3ae/src/lib/processes/toc.py is basically the anolis2 code for it |
| 20:16 | <gsnedders> | Which has a lot less other stuff mixed in with it, so almost certainly the outliner could quite trivially be moved to using that |
| 20:18 | <foolip_> | first pass to actually build the outline is what I want then I suppose |
| 20:18 | <foolip_> | ok, I'll have a look |
| 20:18 | <foolip_> | btw, Nga tells me you said some pleasant words on Facebook, and you're welcome :) |
| 20:18 | foolip_ | mostly reads Facebook by proxy |
| 20:19 | <AryehGregor> | annevk, where should I send feedback about Web DOM Core? |
| 20:19 | <Ms2ger> | p-webapps |
| 20:19 | <Ms2ger> | Read the sotd ;) |
| 20:19 | <AryehGregor> | Blech, another mailing list. |
| 20:20 | <AryehGregor> | No Bugzilla component. Oh well. |
| 20:20 | <Ms2ger> | I guess whatwg would work to |
| 20:21 | <foolip_> | gsnedders, your web service outliner tells me 500 Internal Server Error when trying to outline complete.html :) |
| 20:21 | <AryehGregor> | I guess I'll have to sign up to public-webapps eventually. |
| 20:22 | <AryehGregor> | But I'll put it off for a while longer. |
| 20:23 | <AryehGregor> | annevk, is mail to whatwg okay for DOM Core feedback? |
| 20:25 | <annevk> | AryehGregor, sure |
| 20:26 | <AryehGregor> | k. |
| 20:26 | <annevk> | AryehGregor, or public-webapps |
| 20:26 | <annevk> | oh, you're not on public-webapps |
| 20:26 | <AryehGregor> | Nope, not yet. |
| 20:26 | <annevk> | MikeSmith, you around? if you are, can you make a bugzilla component for DOM Core ? |
| 21:33 | <gsnedders> | If arguments.caller is undefined does that imply the function was called from a timer, or event, or some such? |
| 21:36 | <bga_> | i guess, yes |
| 21:37 | <bga_> | but may be just js engine does not supports arguments.caller :) |
| 21:37 | <gsnedders> | Nah, definitely not that. :) |
| 21:37 | <bga_> | because its has deprecated |
| 21:37 | <gsnedders> | The web would break in a big way if you dropped it. |
| 21:38 | <gsnedders> | Trying to access it throws in strict mode, though |
| 21:38 | gsnedders | simply does not understand where this function call is coming from |
| 21:42 | <bga_> | gsnedders `try{ throw ''} catch(err) { console.log(err.stack) }` iirc |
| 21:43 | <bga_> | or console.trace if engine supports it |
| 21:43 | <gsnedders> | bga_: FWIW, in everything but Carakan you don't need to actually throw the exception to get the stack |
| 21:44 | <gsnedders> | (The stack is that of where the error is created in SpiderMonkey/V8, and where the error is thrown in Carakan) |
| 21:51 | <bga_> | gsnedders how can i get stacktrace in opera. Say me please :) |
| 21:52 | <miketaylr> | console.trace() sort of works using the experimental dragonfly |
| 21:53 | <gsnedders> | bga_: alert(Error().stack) or alert(Error().stacktrace) both work |
| 21:53 | <bga_> | thanks |
| 21:53 | bga_ | notes |
| 21:54 | <gsnedders> | bga_: What you quoted above works too |
| 21:54 | <jamesr_> | why not use a real debugger? |
| 21:54 | <gsnedders> | bga_: It's just needlessly verbose |
| 21:55 | <gsnedders> | jamesr_: In my case? Because it disables JIT, which is rather useless for debugging JIT bugs :) |
| 21:57 | <bga_> | miketaylr is opera still buggy with >>> operator? |
| 21:58 | <miketaylr> | bga_: no idea ;) |
| 21:58 | <gsnedders> | bga_: With 0 on RHS? No. |
| 21:59 | <gsnedders> | Fixed in 2.6.34/2.7.34 |
| 21:59 | <bga_> | good |
| 22:00 | <gsnedders> | There is however a bug with 0 on the RHS of signed shift on ARM JIT |
| 22:00 | <gsnedders> | (unlike the other bug, the LHS has to be non-immediate) |
| 22:03 | <gsnedders> | e.g., Math.cos(0) >> 0 returns 0 and not 1 |
| 22:06 | <bga_> | gsnedders i use `str.slice(0, str.indexOf('foo') >>> 0)` pattern often |
| 22:08 | <TabAtkins> | I don't understand the function of that pattern. |
| 22:08 | <bga_> | -1 >>> 0 == UINT_MAX |
| 22:09 | <TabAtkins> | Ah, got it. |
| 22:09 | <TabAtkins> | So, when the substring is missing, you want the whole thing? |
| 22:09 | <bga_> | yes |
| 22:09 | <jamesr_> | clever |
| 22:09 | <TabAtkins> | Oh, well duh. You're slicing everything before the substring. |
| 22:11 | <gsnedders> | Or if you believe what Carakan used to do when that was JITed, -1 >>> 0 == -1 |
| 22:13 | <MikeSmith> | annevk: here now |
| 22:15 | <Hixie> | AryehGregor: nice tests |
| 22:16 | <AryehGregor> | Hixie, are you able to spot any tests that any browser fails or passes in the second or third test where it gets the opposite outcome in the first test? |
| 22:16 | <Hixie> | not so far |
| 22:16 | <Hixie> | which is good :-) |
| 22:17 | <annevk> | MikeSmith, hey, wanted to ask for a Bugzilla component for DOM Core and CSSOM |
| 22:17 | <annevk> | MikeSmith, and also, I guess, why HTML5 has not been published |
| 22:17 | <Hixie> | AryehGregor: i guess either these selections apis are really well implemented, or we'll have to try harder to find bugs :-) |
| 22:17 | <MikeSmith> | annevk: publishing delay is as usual because of me |
| 22:18 | <AryehGregor> | Hixie, there are bugs all over the place, but I doubt there are too many in mapping user selection to Selection objects. |
| 22:18 | <AryehGregor> | Probably some, but given how hard that is to test right now, I don't think it's worth focusing on. |
| 22:18 | <annevk> | AryehGregor, did you play with CSS styling, newlines in the DOM, white-space:pre, etc.? |
| 22:18 | <Hixie> | AryehGregor: yeah, these tests are probably reasonable until we have a better automation story |
| 22:18 | <MikeSmith> | annevk: we want "Web DOM Core", right? |
| 22:18 | <AryehGregor> | No, and I'm sure I could find some inconsistencies if I did. (Hard to call them "bugs" when it's not specified.) |
| 22:18 | <annevk> | AryehGregor, e.g. a display:none block in the middle of a selection |
| 22:19 | <annevk> | MikeSmith, lets call it "DOM Core" |
| 22:19 | <MikeSmith> | ok |
| 22:19 | <Hixie> | annevk: those are more about the api than interactive user selections |
| 22:19 | <AryehGregor> | But the programmatic interfaces are likely to have vastly more inconsistencies, since they're so much more complicated. |
| 22:19 | <AryehGregor> | Yeah, something with display: none should be detectable programmatically. |
| 22:19 | <Hixie> | annevk: so they'll end up being tested more once AryehGregor has done more work in defining the rest of the api ;-) |
| 22:19 | <annevk> | fair enough |
| 22:19 | <Hixie> | or possibly just before, so he knows what to spec :-) |
| 22:20 | <annevk> | I didn't actually check any test. Just mentioned a few known issues |
| 22:20 | <Hixie> | right, back to http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129 |
| 22:20 | <annevk> | I think Selection is sort of a minefield. Much like innerText |
| 22:21 | <Hixie> | hopefully exactly like innerText |
| 22:22 | <MikeSmith> | annevk: http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG (done for DOM Core) |
| 22:23 | <MikeSmith> | annevk: CSS WG has no product within bugzilla |
| 22:23 | <annevk> | MikeSmith, hmm, can you move components later? I would not mind it being part of WebApps for now for instance |
| 22:24 | <annevk> | just so that people can log requests and Hixie can reassign html5 stuff that ought to be "cssom" |
| 22:24 | <annevk> | MikeSmith, and many thanks btw |
| 22:25 | <MikeSmith> | ok |
| 22:25 | MikeSmith | adding now |
| 22:28 | <MikeSmith> | annevk: URL for editors version of CSSOM? |
| 22:28 | <MikeSmith> | http://dev.w3.org/csswg/cssom/ ? |
| 22:29 | <annevk> | yeah |
| 22:29 | <MikeSmith> | should move that to dvcs… |
| 22:29 | <MikeSmith> | anyway, I'll put that for now |
| 22:29 | <annevk> | most of my specs are still on dev.w3.org |
| 22:29 | <MikeSmith> | CSSOM arguably should be in WebApps anyway |
| 22:31 | <MikeSmith> | k |
| 22:31 | <MikeSmith> | added |
| 22:31 | <MikeSmith> | http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG |
| 22:32 | <MikeSmith> | not to start anything, but that spec really should be renamed |
| 22:33 | <annevk> | file a bug? |
| 22:33 | <MikeSmith> | back to DOM Style |
| 22:33 | <MikeSmith> | or something |
| 22:33 | <MikeSmith> | no |
| 22:34 | <Hixie> | i recommend you name it HTML5 |
| 22:34 | <Hixie> | that way it'll move the heat away from the web apps 1.0 spec |
| 22:34 | <MikeSmith> | as much as I do love to get into a little bikeshedding now and then |
| 22:35 | <MikeSmith> | wink wink nudge nudge |
| 22:35 | <Hixie> | you're saying you think it should be called BikeShedOM? |
| 22:35 | <Hixie> | i could get behind that |
| 22:35 | <MikeSmith> | heh |
| 22:35 | <MikeSmith> | me too |
| 22:35 | <MikeSmith> | wink wink nudge nudge |
| 22:35 | <MikeSmith> | get behind it |
| 22:35 | <annevk> | it's fairly CSS-specific, so DOM CSS could be it I suppose, but really most of it is about an object model for CSS |
| 22:35 | <Hixie> | all right, i printed their proposal and their CP, now i just have to go through it line by line and make sure anything wrong is mentioned in the CCP |
| 22:36 | <annevk> | the ideal way this would be solved is by the big CSS rewrite |
| 22:36 | <Hixie> | that'd be nice |
| 22:37 | <Hixie> | i think i just heard anne volunteer, too |
| 22:37 | <annevk> | much like instead of SVG and DOM SVG we have SVG; instead of HTML and DOM HTML we have HTML; instead of CSS and CSSOM we have ... well |
| 22:38 | <annevk> | I see it is time to hide |
| 22:39 | <MikeSmith> | good thinking |
| 22:39 | <MikeSmith> | that last part |
| 22:39 | <MikeSmith> | about hiding |
| 22:40 | <MikeSmith> | foolish consistency is the hobgoblin of little minds |
| 22:40 | <MikeSmith> | the platform itself of riddled with inconsistencies |
| 22:40 | <MikeSmith> | as are the people and groups who created it |
| 22:40 | <MikeSmith> | thus, the organization of the specs |
| 22:41 | <MikeSmith> | somebody should write some kind of axiom or law or something about that |
| 22:44 | <karlcow> | MikeSmith: Would it have a OM? |
| 22:45 | <MikeSmith> | karlcow: no, but maybe a Way or or a 道 |
| 22:45 | <annevk> | "Please leave your sense of logic at the door, thanks!" |
| 22:45 | <karlcow> | aaaah not a ॐ |
| 22:46 | <karlcow> | Om̐ |
| 22:46 | <MikeSmith> | maybe we could call it the Law of コン道 |
| 22:46 | <karlcow> | :D |
| 22:47 | <karlcow> | which without doubt gives in French, "the way of men" La voie des hommes |
| 22:47 | <MikeSmith> | http://translate.google.com/#en|ja|%E3%82%B3%E3%83%B3%E9%81%93 |
| 22:48 | <MikeSmith> | oofs |
| 22:49 | <MikeSmith> | http://translate.google.com/#ja|en|%E3%82%B3%E3%83%B3%E9%81%93 |
| 22:49 | <annevk> | "con way" |
| 22:49 | <karlcow> | la voie des cons est moins prosaique ;) |
| 22:49 | <MikeSmith> | Kon-dō |
| 22:50 | <karlcow> | I wonder if wikitionary has a good translation of con |
| 22:50 | <karlcow> | http://fr.wiktionary.org/wiki/con |
| 22:51 | <karlcow> | he can mean moron or cunt depending on the circumstance |
| 22:52 | <karlcow> | s/he/it |
| 22:53 | <MikeSmith> | La voie de l'échec |
| 22:54 | <Hixie> | hey, guys, can we keep the language less offensive (in any language)? |
| 22:55 | <karlcow> | ah cultural clash |
| 22:55 | karlcow | will comply |
| 22:55 | <Hixie> | the last thing we need is this channel's rude language getting quoted in the Times or something |
| 22:55 | <Hixie> | thanks |
| 22:55 | <annevk> | I think that would be hilarious |
| 22:56 | <annevk> | and probably less damaging PR-wise than saying we're done in 2022 :p |
| 22:56 | <MikeSmith> | we say far more offensive things here often I suppose |
| 22:56 | <MikeSmith> | I do at least |
| 22:57 | <MikeSmith> | the rest of you guys are just too nice all the time |
| 22:57 | <karlcow> | :p |
| 22:58 | <MikeSmith> | you should try sometimes saying something tactless and undiplomatic |
| 22:58 | <MikeSmith> | now that would be novel |
| 22:58 | <MikeSmith> | break some new ground |
| 23:00 | AryehGregor | was very confused just now when he saw an e-mail to "me, whatwg, Alan" and it turned out that "me" was the mailbox part of someone's e-mail address, not Gmail's way of referring to the user |
| 23:10 | <AryehGregor> | TabAtkins, what was the objection to using a fl unit for \ |
| 23:10 | <AryehGregor> | TabAtkins, what was the objection to using a fl unit for flexbox again? |
| 23:11 | <AryehGregor> | It's more or less the way TeX does it, and TeX's design here is very elegant and powerful. |
| 23:11 | <AryehGregor> | A separate property seems confusing, because it makes "width" mean something strange. |
| 23:11 | <TabAtkins> | AlexMog didn't want to introduce a specialized unit just for Flexbox, that has no meaning outside of it. |
| 23:11 | <AryehGregor> | What do you mean, no meaning outside of it? |
| 23:11 | <TabAtkins> | <div display:block; width:1fl;> is meaningless. |
| 23:12 | <AryehGregor> | And not only because it parses as a div with two attributes "display:block;" and "width:1fl;" whose values are both the empty string, I take it. |
| 23:12 | <AryehGregor> | Hmm. |
| 23:12 | <TabAtkins> | Yes, of course. That's just a shorthand. |
| 23:12 | <AryehGregor> | I guess TeX's entire layout system is based around flex ("glue"), which is why it can get away with allowing flex for all sizes. |
| 23:13 | <TabAtkins> | Yup. |
| 23:13 | <AryehGregor> | But there's no obvious way to shoehorn flex into existing CSS layout models? Why don't you just say that when doing a width or height computation, you use the flexbox algorithm instead of the regular one if there's any flex present? |
| 23:13 | <TabAtkins> | Of course, we can give it meaning outside of Flexbox, but it'll be arbitrary. I support just having it resolve to "0px", frex. |
| 23:13 | <TabAtkins> | No, several things mess up the simplicity of flexbox's algorithm. Floats, for example. |
| 23:14 | <TabAtkins> | If I could, I'd just bolt flex onto the existing block layout. But it's just not possible without an explosion of crazy. |
| 23:14 | <AryehGregor> | Hmm. |
| 23:14 | <AryehGregor> | Existing block layout is really horrible, though. |
| 23:15 | <Hixie> | explosion is right |
| 23:15 | <TabAtkins> | Agreed. |
| 23:15 | <AryehGregor> | It would be nice if it could be mostly replaced by something flex-based. |
| 23:15 | <AryehGregor> | I mean, without removing the old stuff, obviously. |
| 23:15 | <TabAtkins> | Maybe in Flexbox v2. ^_^ |
| 23:15 | <Hixie> | you really want any new system to be completely orthogonal to the existing one, with anything that falls into the existing one being quickly isolated in a root formatting context or whatever the term is |
| 23:16 | <AryehGregor> | Yeah, that's what we should ideally be aiming for, IMO. |
| 23:16 | <Hixie> | also this would be a good time to point out the mistake of having display, float, and position bseparate properties :-) |
| 23:16 | <AryehGregor> | Basically a totally different system, where they fit together by just being opaque blocks nested in one another. |
| 23:16 | <TabAtkins> | That isolation is essentially what we're doing with all the new layout modes. |
| 23:16 | <AryehGregor> | How many do you need? |
| 23:16 | <TabAtkins> | I'm working out with Flexbox just what the minimal connection between the layout modes is, so I can document it and spread the same to others. |
| 23:17 | <Hixie> | man, the more i look at this issue 129 CP the more horrified i'm becoming |
| 23:17 | <TabAtkins> | Apparently, several. |
| 23:17 | <TabAtkins> | Block layout, table layout, flexbox layout, and grid alignment/template so far. |
| 23:17 | <AryehGregor> | :/ |
| 23:17 | <TabAtkins> | Each exposes different sets of constraints. |
| 23:17 | <AryehGregor> | I vote for cloning TeX's layout system. |
| 23:18 | <AryehGregor> | Because TeX's layout system is awesome in every imaginable way. |
| 23:18 | <TabAtkins> | Gods no. That's impossibly computationally expensive. |
| 23:18 | <AryehGregor> | Really? Why? |
| 23:18 | <AryehGregor> | It worked on 1980s computers. |
| 23:18 | <TabAtkins> | Because TeX is computationally expensive? |
| 23:18 | <TabAtkins> | Yes, but a browser isn't a static document. |
| 23:19 | <AryehGregor> | What's so expensive about it? |
| 23:19 | <TabAtkins> | There's a reason we don't do even "simple" things like adopting TeX's justification algorithms. |
| 23:19 | <Hixie> | i was just about to say, imagine doing tex justification with :hover rules changing the constraints |
| 23:19 | <AryehGregor> | You mean hyphenation? |
| 23:19 | <Hixie> | tex justification is done at the paragraph level, not the line level |
| 23:19 | <TabAtkins> | No, justification. TeX does fancy justification. Hyphenation does play into that. |
| 23:19 | <AryehGregor> | Hmm, yeah, it does. |
| 23:20 | <TabAtkins> | Hixie: Even worse, Transitions on width triggered by :hover. |
| 23:20 | <AryehGregor> | It's kind of obnoxious that static content display has to be degraded so much to account for edge cases where the page is dynamic. |
| 23:20 | <AryehGregor> | HTML line-breaking and hyphenation is a shambles. |
| 23:20 | <TabAtkins> | Dynamic pages aren't an edge case. ^_^ |
| 23:21 | <AryehGregor> | Are too. The vast majority of pages don't have text being dynamically added or removed from paragraphs after initial page setup. |
| 23:21 | <TabAtkins> | There's nothing preventing us from offering expensive things as only valid within print, except for the low benefit. |
| 23:22 | <jamesr_> | you never resize your browser window? |
| 23:22 | <AryehGregor> | jamesr_, no, I use it full-screen. But even if I did, I wouldn't do it more than once every few minutes. |
| 23:25 | <AryehGregor> | "Various browsers allow timeouts up to some small level of nesting to run arbitrarily quickly; that started because it happens to make JSBench run faster due to the broken way that benchmark is constructed." :( Yay benchmarks. |
| 23:26 | <TabAtkins> | Yay, apparently my video/canvas demos will work in internal IE9 now. |
| 23:26 | <TabAtkins> | Or rather, they'll work when I switch to using closures in my setTimeout instead of argument forwarding. |
| 23:26 | <TabAtkins> | The important parts will work. |
| 23:39 | <AryehGregor> | Hixie, so when reverse-engineering, if Firefox throws some NS_SOMETHING_ERR exception, should I pick the most reasonable-looking DOMException and say to throw that instead? |
| 23:39 | <Hixie> | seems reasonable |
| 23:40 | <AryehGregor> | Does anyone know how old the Selection stuff is? Are we talking Netscape days or more recent? |
| 23:41 | AryehGregor | is trying to figure out how much stuff is likely to depend on Firefox's behavior vs. WebKit's or Opera's |
| 23:41 | <AryehGregor> | If it's very old and WebKit only reverse-engineered it recently, I should really favor Firefox heavily for compat. |
| 23:42 | <Hixie> | i'd expect it was new with gecko, but that's just a wild guess |
| 23:45 | <bckenny> | TabAtkins: wait, drawing a video in canvas in IE9 no longer sets origin-clean to false? |
| 23:45 | <TabAtkins> | bckenny: I dunno, haven't tried it myself yet. Just heard through the grapevine that my demos work now. |
| 23:45 | <karlcow> | http://geekandpoke.typepad.com/geekandpoke/2011/01/conversation-gaps.html |
| 23:46 | <bckenny> | nice |
| 23:49 | <gsnedders> | AryehGregor: Don't copy us, Firefox/WebKit's behaviour around edge-cases is relied upon by, e.g., Facebook causing some stuff to break in Opera :( |
| 23:49 | <AryehGregor> | gsnedders, okay, noted. |
| 23:50 | <webr3> | http://rim.jobs |
| 23:51 | <TabAtkins> | Holy crap. |
| 23:51 | <webr3> | i know lol - Research In Motions nice new job site - marketing fail or what |
| 23:55 | <Hixie> | one has to assume that they are not oblivious to this... they'll probably get all kinds of viral marketing |
| 23:55 | <Hixie> | as e.g. above :-) |
| 23:56 | <Hixie> | man, working on this CP is positively draining |
| 23:57 | <hober> | Hixie: when is it due? I have yet to chip in, but will be able to help out a bunch on it early/mid next week |
| 23:57 | <Hixie> | 17th i think |
| 23:57 | <hober> | errr |
| 23:58 | <hober> | hmm. I dunno if I'll be able to do much with it before then |
| 23:58 | <Hixie> | k |
| 23:58 | <Hixie> | well if anyone else wants to jump in, be my guest :-) |
| 23:58 | <hober> | 18/19/20th would be a different story |
| 23:58 | <Hixie> | http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-129 |
