| 00:00 | <erlehmann> | it makes chrome not want to close tabs immediately. :/ |
| 00:00 | <sicking> | Hixie: i.e. we haven't talked to them |
| 00:00 | <zewt> | because animated gifs as favicons wasn't annoying enough :) |
| 00:00 | <Hixie> | sicking: k |
| 00:00 | <sicking> | Hixie: the most backwards-breaking change is removing the after-onload-popstate event |
| 00:01 | <erlehmann> | sicking, wait until people implement text adventures using the history API. or zsh. |
| 00:01 | <Hixie> | sicking: well if the browsers are doing different things anyway i guess the compat story is weaker and it might be a non-issue. |
| 00:01 | <sicking> | Hixie: it seems like most people are filtering out that event though |
| 00:01 | <Hixie> | sicking: yeah |
| 00:01 | <zewt> | sigh I hate window methods that break when moved off of window |
| 00:02 | <sicking> | erlehmann: seems like firefox is doing ok on that page for what it's worth |
| 00:02 | <sicking> | zewt: such as? |
| 00:02 | <erlehmann> | still, a rate limiter would help with this kind of history abuse. |
| 00:02 | <zewt> | (tried to do window.URL = { createObjectURL: window.createObjectURL } in Chrome but will need to be a wrapper instead, oh well) |
| 00:03 | <sicking> | zewt: oh, yeah, due to how the DOM is implemented I'd expect that to break in all browsers |
| 00:03 | <zewt> | it's more annoying for console.log than anything else |
| 00:03 | <sicking> | zewt: i.e. due to it being implemented in C++, I'd expect that not to work |
| 00:17 | <gsnedders> | Yay host objects |
| 00:22 | <zewt> | spoiled by python method binding, heh |
| 00:23 | <TabAtkins> | zewt: That's due to binding, right? If not called through 'window', 'this' is bound to undefined. |
| 00:23 | <zewt> | right |
| 00:23 | <zewt> | heh what the |
| 00:23 | <zewt> | okay this one's weird |
| 00:23 | <TabAtkins> | Yeah, we just need to fix the binding behavior of javascript. |
| 00:23 | <uf0> | what exactly does "initial-scale=1.0" do for mobile? |
| 00:24 | <zewt> | i do window.history.pushState = null, which works ... but five seconds later, it's reset to the method |
| 00:25 | <zewt> | anyone want to see if I'm going insane? http://zewt.org/~glenn/test-ff4rc1-pushState-assignment.html logs four times; after the last, after a long timer, pushState is back from the dead |
| 00:25 | <zewt> | er, ff4rc1 |
| 01:14 | <gsnedders> | TabAtkins: What it's called through doesn't matter, Function.prototype.{apply,call,bind} allow functions to be called with any value as the thisArg |
| 01:14 | <TabAtkins> | gsnedders: Yes, of course. |
| 01:15 | <TabAtkins> | gsnedders: zewt's use was just ripping the function off, without binding or explicit calling. |
| 05:52 | <alystair> | is there any reason the whatwg specs pages are able to bring firefox to its knees |
| 05:53 | <alystair> | looks like it froze it |
| 05:54 | <alystair> | pegging my cpu |
| 05:55 | <MikeSmith> | alystair: multi-page version: http://whatwg.org/C |
| 05:55 | <doublec> | it does that for the single page version, yes |
| 05:56 | <alystair> | firebug should not link |
| 05:56 | <alystair> | <meta charset=utf-8> |
| 05:56 | <alystair> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">; |
| 05:56 | <alystair> | <html xmlns="http://www.w3.org/1999/xhtml"; <?php language_attributes(); ?>> |
| 05:56 | <alystair> | er |
| 05:56 | <alystair> | whoory |
| 05:57 | <alystair> | sorry hotkey fiesta, I'll leave now, too sleep deprived :S |
| 07:28 | <Hixie> | i need an algorithm that has as input an integer in the range 0..N where N is at least 32, and has as output an RGB triple, such that: |
| 07:28 | <Hixie> | * all the outputs are distinguishable colours |
| 07:29 | <Hixie> | * the outputs are deterministic (a given input always gives the same output) |
| 07:29 | <Hixie> | * the colors in the range 0..n where n < N are clearly distinct |
| 07:30 | <Hixie> | * earlier colours are especially distinct, e.g. the colours of the rainbow |
| 07:30 | Hixie | ponders |
| 07:54 | <nessy> | Hixie: map the first #FFFFFF numbers to n numbers and then re-use those n numbers until you have N? |
| 07:55 | <Hixie> | come again? |
| 07:55 | <Hixie> | oh, by "the colors in the range 0..n where n < N are clearly distinct" i just meant that given any subrange starting from 0, the colours have to be distinct |
| 07:55 | <Hixie> | so e.g. it's not the seven colours of the rainbow followed by 8 shades of red |
| 07:56 | <Hixie> | then 8 shades of green, etc |
| 07:56 | <Hixie> | right now my solution is to just have a hard-coded list of colours for 0..N, but that forces me to have a small N (15 in this case). |
| 08:08 | <annevk> | Would love an email client that lets you stick emails together |
| 08:08 | <Hixie> | pine |
| 08:08 | <Hixie> | is what i use |
| 08:08 | <annevk> | For when people use email clients that screw up threading |
| 08:08 | <Hixie> | works like a charm |
| 08:09 | <annevk> | :)d |
| 08:09 | <Hixie> | just select multiple e-mails then hit Apply Reply |
| 08:09 | <Hixie> | (a r) |
| 08:09 | <annevk> | that's a pretty nifty feature, but I meant for when going through my inbox later one thread would actually appear as one |
| 08:10 | <Hixie> | pine does that too :-) |
| 08:10 | <Hixie> | sort by thread groups threads with the same subject |
| 08:10 | <Hixie> | we really need to have a better solution for rotated text in table cells than embedded svg |
| 08:10 | <annevk> | can you also group seemingly unrelated emails? like you can do with apps on your iPhone? |
| 08:11 | <Hixie> | no, but mostly because i don't have an iphone |
| 08:11 | <Hixie> | what do you mean, "group seemingly unrelated emails"? |
| 08:11 | <annevk> | that would be kind of neat too, grouping all feedback for one particular spec |
| 08:11 | <Hixie> | specifically what do you mean by "group" |
| 08:11 | <annevk> | i guess you just create folders and such |
| 08:12 | <Hixie> | you can do select by recipient, zoom: ";trpublic-html[ENTER]z" for example will just limit the view to e-mails from the html list |
| 08:12 | <annevk> | hmm, in Opera Mail a thread is "group" of related emails that can be collapsed into one so you can see a lot more emails than just that thread |
| 08:12 | <Hixie> | you can collapse threads, but you can't collapse multiple unthreaded e-mails in pine, no |
| 08:13 | <Hixie> | but you rarely need to, since you just use the zoom feature all the time instead |
| 08:20 | <annevk> | very much liking it that Jukka is active on the list now |
| 08:21 | <Hixie> | except for him bringing up issues we resolved literally half a decade ago... |
| 08:22 | <Hixie> | svg is hard |
| 08:22 | <annevk> | apparently our resolutions are not very clear then :) |
| 08:22 | <Hixie> | how the heck do i make it so that the x= y= coordinate i give a <text> refers to the bottom left of the bounding box of the em boxes? |
| 08:22 | <annevk> | it's evident from his emails that he has read the spec |
| 08:23 | <annevk> | Hixie, hmm yeah, the coordinate system always bites me too |
| 08:23 | <Hixie> | i'm staring at the svg 1.1 spec's text chapter with very little understanding |
| 08:23 | <Hixie> | all i want to do is have the text in a cell of a table be vertical instead of horizontal |
| 08:23 | <Hixie> | that shouldn't be this hard |
| 08:24 | <Hixie> | i'm even willing to give explicit heights and widths, though i shouldn't hav eto |
| 08:25 | <annevk> | apply a transform/ |
| 08:25 | <annevk> | ? |
| 08:25 | <annevk> | i don't think SVG has vertical text |
| 08:25 | <Hixie> | css transforms aren't implement as non-vendor-specific properties by anyone as far as i can tell |
| 08:25 | <Hixie> | also css transforms don't really work for this since they happen after layout as far as i can tell |
| 08:26 | <annevk> | SVG has transforms |
| 08:26 | <Hixie> | oh, sure, that's how i'm rotating the text |
| 08:26 | <Hixie> | but i don't really see how to get the right rotation |
| 08:27 | <annevk> | oh, transforms in SVG are around 0,0 |
| 08:27 | <annevk> | I think |
| 08:27 | <Hixie> | you can pass an explicit coordinate to do the transform around |
| 08:27 | <Hixie> | rotate(angle, cx, cy) |
| 08:27 | <Hixie> | but as far as i can tell you can't use units there |
| 08:27 | <Hixie> | you have to use pixels |
| 08:27 | <Hixie> | which means you have to use viewBox to set the coordinate system |
| 08:27 | <Hixie> | except then my coordinate system isn't square |
| 08:27 | <Hixie> | gah |
| 08:28 | <annevk> | good times? :p |
| 08:28 | <annevk> | maybe you should just stick with an HTML table for now and outsource the SVG bit |
| 08:32 | <Hixie> | ok i give up on svg |
| 08:32 | <Hixie> | what else can i use |
| 08:32 | <Hixie> | i guess i could do it with canvas |
| 08:32 | <Hixie> | that would be ridiculous |
| 08:32 | <Hixie> | but i guess it'd work |
| 08:35 | <annevk> | heycam, don't we have the array type for that? |
| 08:36 | <annevk> | heycam, and which specifications are using it then? |
| 08:37 | <annevk> | Hixie, why do care so much about the presentation? |
| 08:37 | <Hixie> | annevk: it's for a home project i'm working on |
| 08:39 | <annevk> | so the last two very short blog posts are found way more interesting on twitter than any of the summary blog posts |
| 08:39 | <annevk> | measured by RTs |
| 08:40 | <annevk> | latest WHATWG Weekly: 1 RT; HTML5 for Web Developers: 20 RT; Validator.nu update: 16 RT |
| 08:40 | <Hixie> | what about hits? |
| 08:40 | annevk | looks |
| 08:41 | <annevk> | Hixie, can you add my email to the analytics account for the frontpage btw? |
| 08:41 | annevk | is curious |
| 08:41 | Hixie | wonders how to do that |
| 08:41 | <Hixie> | username? |
| 08:42 | <annevk> | annevankesteren⊙gc |
| 08:43 | <annevk> | in terms of pageviews it's HTML5 for Web Developers; latest WHATWG Weekly; Validator.nu update |
| 08:43 | <Hixie> | done |
| 08:44 | <annevk> | though even more popular even over the last 10 days is the road to contenteditable |
| 08:44 | <annevk> | and just after HTML5 for Web Developers is HTML is the new HTML5 |
| 08:44 | <annevk> | still going strong :) |
| 08:45 | <Hixie> | i don't understand why analytics isn't picking up any of the clicks on the home page |
| 08:52 | <annevk> | http://www.pinkbike.com/news/DNS-Prefetching-implications.html |
| 08:54 | <annevk> | I can't find anything about that <meta> in either HTML or the WHATWG Wiki :/ |
| 08:55 | <annevk> | https://developer.mozilla.org/en/controlling_dns_prefetching#Controlling_prefetching_from_content |
| 08:55 | <Hixie> | add it :-) |
| 08:56 | <annevk> | the HTTP header is X- prefixed and the rel value is squatted, makes so much sense... |
| 08:57 | <Hixie> | i love when people ship x- http headers on the basis that that's easier than registering them |
| 08:57 | <Hixie> | and then people argue the problem is with them, not the registration system :-) |
| 08:58 | <annevk> | one of the IETF ADs did put out a draft suggesting people no longer do that |
| 08:58 | <Hixie> | ok so using canvas i've been able to actually get the text to display in the right place, but now i am fighting a web font issue |
| 08:58 | <Hixie> | i guess i have to postpone drawing the canvas until after onload |
| 08:58 | <annevk> | maybe I should advertise that draft somewhere so people actually notice |
| 08:58 | <Hixie> | also getting the font size is non-trivial |
| 08:59 | <Hixie> | "parseInt(getComputedStyle(canvas, '')['font-size'], 10)" |
| 08:59 | <Hixie> | there has to be a better way to do that |
| 08:59 | <Hixie> | like canvas.runtimeStyle.fontSize.px or something |
| 09:00 | <Hixie> | (why didn't we support context.font = 'inherit'?) |
| 09:00 | <annevk> | something like canvas.resolvedValue.values.fontSize.px or some such has been proposed |
| 09:00 | <annevk> | euh, resolvedStyle |
| 09:01 | <annevk> | still waiting for some experimental implementations before drafting everything |
| 09:01 | <annevk> | they have been told to be coming, but it looks like it will be a while |
| 09:01 | <annevk> | though I guess at some point I should just write it all out |
| 09:01 | <annevk> | and see if that has better results |
| 09:02 | <zcorpan> | Hixie: http://lists.w3.org/Archives/Public/public-html/2009Jul/0947.html |
| 09:03 | <Hixie> | zcorpan: that ian guy is such a moron. i wish he had just done what i want instead. :-P |
| 09:03 | <Hixie> | i'm getting weirdly unreliable effects even waiting until onload |
| 09:03 | <Hixie> | do fonts not delay onload? |
| 09:03 | <zcorpan> | fonts should delay onload |
| 09:04 | <zcorpan> | at least in impl, don't recall if there's a spec that says so |
| 09:06 | <zcorpan> | Hixie: maybe you should learn from the inherit thing and do what i say next time? :) |
| 09:07 | <Hixie> | not if you don't give use cases :-) |
| 09:07 | <annevk> | http://wiki.whatwg.org/wiki/PragmaExtensions added the x-... thingie. dns-prefetch was already registered |
| 09:08 | <annevk> | http://wiki.whatwg.org/wiki/RelExtensions should we remove archives and such now? |
| 09:08 | <Hixie> | i haven't bothered removing anything from RelExtensions yet because i'm waiting for a decision on what the spec should say |
| 09:08 | <Hixie> | about registering values |
| 09:09 | <annevk> | at this point I don't think I want to accept anything but a wiki-based approach |
| 09:10 | <annevk> | the idea of maintaining it in the spec is somewhat nice, but doesn't work well for experimental values |
| 09:10 | <Hixie> | yeah it's pretty clear to me now that the right solution is to have a wiki page where you can register values, the values time out after a year with no proof of implementation, and the good ones get moved into the spec. |
| 09:11 | <annevk> | sounds reasonable |
| 09:11 | <Hixie> | dunno how to get the chairs to go for that since it's a new proporasl |
| 09:11 | <Hixie> | proposal |
| 09:12 | <Hixie> | (seriously, anyone know how to change the baseline alignment for <text> in svg? i want to align something based on the em box and not the alphabetic baseline, but can't work out how to do it. the spec is very confusing.) |
| 09:12 | <annevk> | so you want the coordinates to be from the bottom or something? |
| 09:12 | <Hixie> | or the top, either would work |
| 09:13 | <annevk> | http://stackoverflow.com/questions/56402/aligning-text-in-svg ? |
| 09:14 | <Hixie> | style="dominant-baseline:top" doesn't seem to do anything in chrome |
| 09:15 | <Hixie> | let's try firefox |
| 09:15 | <Hixie> | nope |
| 09:16 | <Hixie> | ah because apparently it's spelt "text-before-edge" |
| 09:16 | <Hixie> | how intuitive |
| 09:16 | <annevk> | dominant-baseline is rather intuitive too |
| 09:16 | <Hixie> | this seems to be based on the bounding box not the em box |
| 09:16 | <Hixie> | maybe that's a chrome bug |
| 09:17 | <Hixie> | works in firefox |
| 09:18 | <Hixie> | next question, why isn't it rendering in the color i'm specifying |
| 09:19 | <Hixie> | oh, right. i have to set fill="currentColor". |
| 09:19 | <annevk> | that seems like a bug |
| 09:20 | <annevk> | oh no |
| 09:21 | <Hixie> | is there an svg test suite? |
| 09:21 | <annevk> | "The ‘color’ property is used to provide a potential indirect value (currentColor) for the ‘fill’, ‘stroke’, ‘stop-color’, ‘flood-color’ and ‘lighting-color’ properties." but the initial value for 'fill' is black... |
| 09:21 | <annevk> | http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview |
| 09:21 | <Hixie> | as far as i can tell, none of these tests test dominant-baseline |
| 09:22 | <Hixie> | gotta wonder how they got out of CR |
| 09:22 | <Hixie> | probably the same way HTML5 is gonna hit REC in 2014... |
| 09:22 | <annevk> | with 275 tests it's pretty clear not every feature is tested |
| 09:23 | <Hixie> | ok, well, hardcoding the font size, the shrink-wrap dimensions, and the baseline offset, i was able to make this work using svg. |
| 09:23 | <Hixie> | i'm going to say that as a platform, we've really dropped the ball on this particular feature. |
| 09:26 | <annevk> | SVG is way hard |
| 09:26 | <Hixie> | well to be fair this really should be solved in css |
| 09:26 | <Hixie> | and i guess it will be with vertical text |
| 09:27 | <Hixie> | though that doesn't handle the slight-angle case |
| 09:27 | <annevk> | in retrospect I think SVG should have been part of "XBL" in some way |
| 09:27 | <annevk> | to prettify semantics, but not to describe applications by itself |
| 09:28 | <Hixie> | yeah |
| 09:28 | <Hixie> | but it was originally intended to replace flash, as i understand it |
| 09:29 | <Hixie> | and now it's too late to do it right |
| 09:29 | <Hixie> | the browser vendors (me included) totally dropped the ball on svg because we ignored it until too late |
| 09:29 | <annevk> | yeah, Adobe pushed for it to replace Flash |
| 09:29 | <annevk> | then bought Flash |
| 09:29 | <annevk> | and stopped caring (mostly) |
| 09:29 | <annevk> | and we got stuck with it |
| 09:33 | <annevk> | but yeah, also our own fault |
| 09:33 | <annevk> | cannot really fix something you're not actively involved in |
| 09:37 | <annevk> | AryehGregor, http://weblogs.mozillazine.org/roc/archives/2011/03/the_myth_of_ful.html seems to indicate the IE blog post was indeed misleading |
| 09:37 | <annevk> | AryehGregor, in tradition with their other blog posts |
| 09:45 | <Hixie> | nn |
| 09:46 | <annevk> | g'night |
| 09:52 | <hsivonen> | AryehGregor: you may also be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=638241 |
| 09:52 | <hsivonen> | AryehGregor: in that case, Firefox lost to IE on the FishTank not because of hardware acceleration flaws but because of same-origin checks |
| 09:53 | <hsivonen> | so basically, one can't really attribute slowness to what the benchmark says it's testing without actually profiling and seeing what's slow |
| 09:57 | <jgraham> | I am told that a peril of hardware acceleration is that you have to be careful not to regress performance in areas where the CPU is relatively fast |
| 10:28 | <annevk> | I'm back on Android again |
| 10:28 | <annevk> | new iPhone broke in the exact same way |
| 10:28 | <annevk> | I'm still using it through (sometimes by enabling tethering on the Android phone to get things working) as getting it repaired before leaving is not going to happen |
| 10:28 | <annevk> | (It's fully functional apart from the microphone...) |
| 10:32 | <jgraham> | Isn't the microphone quite important on a phone? |
| 10:33 | <annevk> | Well, now phones are computers it's less essential, but it started bothering me enough that I switched. |
| 10:34 | <annevk> | Also, some shop will call me to tell my tent has been repaired and I would like to be able to answer them :) |
| 11:56 | <annevk> | Philip`, is isPointInPath() the only method quite different in browsers with respect to transforms? |
| 11:57 | <annevk> | Philip`, and is Firefox correct per current spec or Opera/WebKit? |
| 11:57 | annevk | thinks it's the former, but isn't quite sure |
| 12:00 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/results.html#2d.path.isPointInPath.transform.1 suggests Firefox is wrong (since I don't think the spec changed since those tests) |
| 12:01 | <Philip`> | I don't remember any other features with a similar problem |
| 12:11 | <annevk> | ooh |
| 12:11 | <annevk> | <800 |
| 12:11 | <annevk> | Philip`, the spec says transforms do not affect isPointInPath() |
| 12:12 | <annevk> | "The isPointInPath(x, y) method must return true if the point given by the x and y coordinates passed to the method, when treated as coordinates in the canvas coordinate space unaffected by the current transformation" |
| 12:13 | <Philip`> | That's what the tests test |
| 12:13 | <Philip`> | (I think) |
| 12:13 | <annevk> | ok |
| 12:14 | <Philip`> | ctx.translate(50, 0); |
| 12:14 | <Philip`> | ctx.rect(0, 0, 20, 20); |
| 12:14 | <Philip`> | _assertSame(ctx.isPointInPath(51, 10), true, "ctx.isPointInPath(51, 10)", "true"); |
| 12:14 | <Philip`> | etc |
| 12:15 | <Philip`> | (The rect() is affected by the transform, at least since that part of the spec got changed) |
| 12:15 | <annevk> | thanks |
| 13:01 | <zcorpan> | need to reboot to install firefox 4 rc on windows 7? |
| 13:03 | <jgraham> | zcorpan: I didn't |
| 13:13 | <Rik`> | zcorpan: that's mandatory to get Bing as a default search :) |
| 13:56 | <annevk> | zcorpan, why is the order of Nodes interfaces the way it is? |
| 13:59 | <annevk> | zcorpan, order of sections that is |
| 14:02 | <zcorpan> | annevk: don't remember, maybe i copied dom3core |
| 14:04 | <annevk> | oh yeah, you did |
| 14:04 | <annevk> | but then it got reshuffled somewhat afterwards |
| 14:49 | <annevk> | jgraham, is there some reason why assert_equals does not handle \0? |
| 15:02 | <jgraham> | annevk: It doesn't? |
| 15:05 | <annevk> | dunno, something seems to fail somewhat |
| 15:18 | <jgraham> | annevk: Show me an example and I will try to fix |
| 15:20 | <annevk> | gonna upload one soon |
| 15:20 | <annevk> | working on some new EventSource tests based on suggestions Hixie gave |
| 15:28 | <smaug____> | annevk: do you have tests for XHR2 and "progress" event? |
| 15:28 | <smaug____> | something which tests that "progress" doesn't fire too often |
| 15:28 | <annevk> | no tests for XHR2 at all |
| 15:28 | <smaug____> | k |
| 15:28 | <annevk> | I was planning on writing CORS tests, but did not get around to it |
| 15:29 | <annevk> | timing tests are particularly annoying :/ |
| 15:29 | <smaug____> | indeed |
| 15:33 | <annevk> | so far I have found one bug in WebKit |
| 15:33 | <annevk> | it does not parse the retry field correctly |
| 15:34 | <annevk> | not sure this was worth all the trouble |
| 15:37 | <annevk> | jgraham, http://tc.labs.opera.com/apis/EventSource/format-field-parsing.htm |
| 15:38 | <zewt> | heh, opera throws a nice exception if you dispatch without initEvent |
| 15:38 | <zewt> | Error: |
| 15:38 | <annevk> | it's very interoperable I hear |
| 15:39 | <zewt> | are there interoperability concerns with having the null string as an error message? :) |
| 15:40 | <annevk> | well it should at least have a code and such |
| 15:44 | <annevk> | zewt, where does DOM Events require a non-null event name? |
| 15:45 | <annevk> | it's defined as such |
| 15:45 | <annevk> | "The name of the event type. The name must be a DOMString. Specifications that define events, content authors, and authoring tools must use case-sensitive event type names that do not contain whitespace characters." |
| 15:45 | <annevk> | which does not say much at all |
| 15:45 | <jgraham> | annevk: I'm not sure what bug I'm supposed to see |
| 15:46 | <zewt> | i remember that being one of the things you explicitly changed in core |
| 15:46 | <zewt> | here it is, in dispatchEvent |
| 15:46 | <annevk> | jgraham, I think the problem might be that under got it says "\0" rather than using an actual zero byte |
| 15:46 | <zewt> | UNSPECIFIED_EVENT_TYPE_ERR: Raised if the Event.type was not specified by initializing the event before dispatchEvent was called. Specification of the Event.type as null or an empty string must also trigger this exception. |
| 15:47 | <annevk> | but it does allow specifications to define events that are the empty string |
| 15:47 | <jgraham> | annevk: That seems more likely to be either a bug in the browser or a problem with your test, no? |
| 15:47 | <annevk> | anyway, there's a separate thread on that too |
| 15:48 | <annevk> | jgraham, could be a problem with the test I suppose |
| 15:48 | <zewt> | i know |
| 15:48 | <zewt> | just tying the two issues together--they should either both go or both stay |
| 15:48 | <jgraham> | annevk: (I don't think it makes a difference but encodeURIComponent seems more appropriate than encodeURI) |
| 15:49 | <zewt> | (removing the null string restriction and then, as a side-effect of that, having to add a new "initEvent was called" flag would just be silly) |
| 15:49 | <zewt> | well strictly speaking, initEvent("", ...) doesn't actually throw by D3E's rules |
| 15:49 | <annevk> | zewt, well that is what Gecko is doing at the moment |
| 15:50 | <annevk> | zewt, they do not have the dispatchEvent() limitation but do have the requirement to invoke initEvent() |
| 15:50 | <zewt> | yeah I think I saw that |
| 15:50 | <zewt> | that's the only browser doing that, right? |
| 15:50 | <annevk> | could be |
| 15:50 | <zewt> | whereas webkit has the null-string check (iirc) |
| 15:50 | <annevk> | but they're happy to change |
| 15:50 | <annevk> | and Opera is too |
| 15:51 | <zewt> | yeah since no real webpages actually want to send the null string as an event i'd hope nobody would dig in their heels on this |
| 15:51 | <smaug____> | ok, as I expected, Chrome does fire "progress" occasionally way too often |
| 15:52 | <smaug____> | 3ms, when it should be every 50ms |
| 15:52 | <zewt> | (i mean, there are no compat issues or anything, this is just a straightforward simplification for everyone) |
| 15:54 | <annevk> | except when you believe in the magical DOM Level 3 Events it seems |
| 15:54 | <annevk> | it defies logic |
| 15:55 | <zewt> | still havn't seen any response from the d3e editor to suggest he'll actually budge on anything ever, heh :| |
| 15:55 | <annevk> | he's on vacation I'm told |
| 15:55 | <zewt> | ah fair enough |
| 15:55 | <annevk> | I asked Ms2ger to take care of pushing to publish DOM Core when I'm goen |
| 15:55 | <smaug____> | yeah, shepazu is on vacation |
| 15:55 | <annevk> | gone* |
| 15:55 | <annevk> | Art is not really willing to do it without a green light from Doug, which is fair enough |
| 15:57 | <zewt> | hopefully d3e will eventually just become a spec for the actual events (the major bulk of that spec) and reference dom core for the underlying event model ... but well heh |
| 15:58 | <zewt> | i mean i agree that having two "parallel" normative specs for the same thing, written completely differently, is ... weird |
| 15:58 | <smaug____> | something like that would be good. Need to just be careful to keep the specs readable |
| 15:59 | <smaug____> | Hmm, though, do events need to be in DOM Web Core |
| 16:00 | <smaug____> | mutation events should be there, if we want to keep supporting them |
| 16:00 | <annevk> | it's nice that the event model is there |
| 16:00 | <smaug____> | why? |
| 16:01 | <annevk> | http://annevankesteren.nl/2011/03/dom-core-events (and some emails on a mailing list which I can't find) |
| 16:02 | <smaug____> | .createEvent is a valid reason |
| 16:02 | <smaug____> | though if we move to new FooEvent, that reason would be gone |
| 16:03 | <annevk> | the method would still be there... |
| 16:03 | <smaug____> | sure, and DOM Core could just refer to Events spec for the result |
| 16:03 | <zewt> | seems like it'd make more sense to define an interface that exposes createEvent, which document (and hopefully WorkerGlobalScope) is a user of--so the event API doesn't have to know about document |
| 16:04 | <smaug____> | I'm mainly just worried about getting another monster spec which includes everything between earth and sky |
| 16:04 | <zewt> | (don't personally care whether events are in DOM Core or a split out DOM Core Events or whatever) |
| 16:05 | <jgraham> | DOM Core hardly seems to be a monster spec |
| 16:05 | <smaug____> | not yet, at least |
| 16:06 | <annevk> | what do you mean not yet? |
| 16:06 | <jgraham> | How much is missing? |
| 16:06 | <annevk> | goals and issues are pretty clearly identified: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#goals |
| 16:06 | <smaug____> | well, if there are features creeping in ... |
| 16:06 | <zewt> | well, there's a big difference between a huge spec that defines a single topic (D3E) and one that defines a bunch of very clearly-separated topics (eg. HTML) |
| 16:07 | <smaug____> | I said "I'm just worried" |
| 16:07 | <annevk> | D3E is a bunch of different topics too imo |
| 16:07 | <annevk> | more so than Events and Nodes are... |
| 16:07 | <zewt> | d3e seems like two topics: the event model and the element events that use it |
| 16:07 | <smaug____> | D3E has several topics, sure |
| 16:07 | <zewt> | (the latter can be broken down further, of course) |
| 16:07 | <annevk> | mouse events are way different from keyboard events |
| 16:07 | <smaug____> | keyevents could be in a separate document |
| 16:08 | <annevk> | mouse events should be tied with 'pointer-events' and hit testing |
| 16:09 | <smaug____> | possibly. And the DOM Events could contain just the event dispatching, which isn't tied to DOM tree, so it wouldn't need to be in DOM core |
| 16:09 | <annevk> | there's two infrastructure things I'd consider for DOM Core |
| 16:09 | <annevk> | the event loop and event handler attributes |
| 16:09 | <annevk> | so you can avoid depending on HTML5 if you need those |
| 16:09 | <annevk> | smaug____, the event model is very small |
| 16:10 | <annevk> | smaug____, not really worth separating it out and duplicating all the boilerplate, duplicating the references required, cross dependency, etc. |
| 16:11 | <zewt> | well, if you remove all of the event definitions from DOM Events, and give it DOM Core's event model description, then it simply becomes a DOM Core Events :) |
| 16:11 | <zewt> | (remove as in move to relevant sections elsewhere) |
| 16:11 | <smaug____> | yeah, DOM Core Events could make sense |
| 16:11 | <annevk> | the events model is 5 pages out of 50 |
| 16:11 | <smaug____> | so |
| 16:12 | <smaug____> | ? |
| 16:12 | <annevk> | so it would just create a bunch of boilerplate and editorial work for no good reason |
| 16:12 | <annevk> | as you always need DOM Core for DOM Events and vice versa |
| 16:12 | <annevk> | exceptions are shared, tree model is shared |
| 16:12 | <annevk> | Node inherits from EventTarget |
| 16:12 | <annevk> | and Document has createEvent() |
| 16:13 | <annevk> | compared with the 500-1000 pages HTML has, I'm really quite pleased it's only 50 |
| 16:13 | <annevk> | 46 even |
| 16:15 | <smaug____> | the old level 2 specs are/were quite readable (I'm not talking about whether they are good specs). |
| 16:15 | <zewt> | annevk: any reason not to define createEvent as an interface implemented by Document? seems more consistent |
| 16:15 | <annevk> | zewt, that's not how it's implemented |
| 16:16 | <zewt> | don't know what user-visible difference it makes |
| 16:16 | <annevk> | zewt, we could still define it in a separate document and make it behave the same as it does now though |
| 16:16 | <annevk> | I just don't see the point |
| 16:16 | <smaug____> | there is certainly implementations which implement DocumentEvent interface |
| 16:17 | <annevk> | sure |
| 16:17 | <smaug____> | s/is/are/ |
| 16:17 | <zewt> | just sort of odd that everything else in there is an interface; that one being different leads to the odd "introduced later ..." note in 4.4, and (although it doesn't really matter yet) means WorkerGlobalScope can't implement it |
| 16:18 | <zewt> | minor thing, just curious |
| 16:18 | <annevk> | WorkerGlobalScope could define a similar method |
| 16:19 | <annevk> | or something similar, no real need to worry about that now |
| 16:20 | <annevk> | but rather than focusing on splitting it out can't we instead focus on the contents for a while? |
| 16:20 | <annevk> | or is it being in the same document the real problem here? |
| 16:23 | <annevk> | the equivalent text in DOM Level 3 Events is over fifteen pages |
| 16:24 | <annevk> | not counting boilerplate, graphs, and definitions |
| 16:24 | <annevk> | if you count those it's over 30 |
| 16:25 | <zewt> | nothing discourages reporting bugs quite like a summary zero-discussion wontfix... |
| 16:25 | zewt | grumbles |
| 16:26 | <annevk> | ? |
| 16:26 | <zewt> | totally off-topic grumbling :) |
| 16:26 | <annevk> | i was already afraid I did something wrong :) |
| 16:26 | <zewt> | sorry :P |
| 16:27 | <zewt> | seems like the urge to split things into tiny chicklet specs is sort of overcompensation for previous giganto-specs |
| 16:28 | <zewt> | since it's not like specs are python modules and splitting them apart is without cost |
| 16:29 | <annevk> | just http://www.w3.org/TR/DOM-Level-3-Core/core.html is already twice as long as DOM Core is today |
| 16:29 | <annevk> | so the mega spec concern really seems unjustified |
| 16:30 | <annevk> | that page is 95 pages |
| 16:30 | <annevk> | DOM Core is 46 |
| 16:30 | <annevk> | that page is not all of DOM Level 3 Core |
| 16:30 | <annevk> | DOM Core also includes the event model |
| 16:30 | <zewt> | even if dom core defined 10x as many features and was 10x as long, I wouldn't be worried--as long as they remain clearly separated with clear relationships between the features |
| 16:31 | <annevk> | me neither, but that seems unlikely to happen and the criticism is not backed with any facts |
| 16:41 | <smaug____> | DOM 2 Core is around 50 pages, and that is still quite readable, especially because that spec doesn't contain too many unrelated features |
| 16:42 | <jgraham> | The main reason DOM 2 Core is readable is that it doesn't really define anything in much detail |
| 16:44 | <annevk> | I get 48 for DOM Level 2 Core |
| 16:45 | <annevk> | that's still two pages more than DOM Core |
| 16:45 | <annevk> | and it doesn't define the event model and lacks a bunch of detail |
| 16:45 | <annevk> | and that is also not counting all the appendices |
| 16:46 | <annevk> | because the count for DOM Core includes references, glossary, acknowledgments, etc. |
| 16:46 | <smaug____> | ok, if dom web core can be kept the size it is now, then good |
| 16:46 | <smaug____> | although the event model isn't strictly core stuff |
| 16:46 | <zewt> | i really don't think it's the size that's the issue |
| 16:47 | <annevk> | I don't really see the issue with that either |
| 16:47 | <smaug____> | size is part of the readability issue |
| 16:47 | <smaug____> | which html spec has now |
| 16:47 | <zewt> | well that's a presentation issue, splitting specs isn't the only possible way to deal with that |
| 16:48 | <zewt> | really need an html spec rendering that's one-page but doesn't choke every browser, heh |
| 16:48 | <smaug____> | that is true |
| 16:48 | <smaug____> | yeah :) |
| 16:48 | <zewt> | it's also slightly ironic to have an html spec that kills browsers :) |
| 16:49 | <annevk> | I suspect DOM Core will grow somewhat as there are a few missing details and we might want to add a little more advice for authors |
| 16:49 | <annevk> | but I can't see it going from 46 to 800 pages or so |
| 16:50 | <annevk> | and we can always split it then |
| 16:50 | <annevk> | at this point complaining about size is illogical given that it's smaller than pretty much every other spec |
| 16:50 | <annevk> | and contains more |
| 16:53 | <smaug____> | I didn't complain the size atm |
| 16:53 | <smaug____> | I said "I'm just worried ...." |
| 16:54 | <smaug____> | and also, for me events aren't part of the core |
| 16:54 | <smaug____> | but yet, I'm happy to see web dom core which removes lots of crazy features of DOM 3 Core |
| 16:55 | <zewt> | doesn't really remove anything, right? just makes it ... comprehensible |
| 16:55 | <annevk> | it removes a lot of unimplemented features (and some implemented ones) |
| 16:55 | <annevk> | see the historical section |
| 16:57 | <zewt> | i have, other than EventException it's just minor changes, not removed features |
| 16:57 | <jgraham> | Attribute ninodes |
| 16:57 | <jgraham> | s/ni// |
| 16:57 | <zewt> | sounds like a medical condition |
| 16:59 | <annevk> | zewt, DOM 3 Core, not DOM 3 Events |
| 17:00 | <zewt> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-events ? |
| 17:01 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-core |
| 17:01 | <zewt> | only "feature removal" (if it can even be called that) listed there is EventException |
| 17:02 | <zewt> | oh, havn't even looked at that stuff |
| 17:06 | <zewt> | annevk: nitpick on Goals: one of the goals of DOM Core is to "Import bits of HTML5 that ought to be in DOM Core", which is sort of recursive |
| 17:08 | <TabAtkins_> | What the *hell* is bug 12284 going on about? |
| 17:12 | <miketaylr> | you know "C" parsing of ... words :/ |
| 17:13 | <TabAtkins_> | I can only guess that he has some fragile/stupid program that tests whether a document is HTML/XML by testing the length of some "word". |
| 17:13 | <miketaylr> | just use .htm, BAM |
| 17:14 | <miketaylr> | assuming that word is a file extension, who knows |
| 17:14 | <TabAtkins_> | If he's using extensions, yeah. But if that would fix his program, then I guess .doc would register as xml? |
| 17:14 | <TabAtkins_> | In any case, it's retarded and I marked it as invalid. |
| 17:14 | <miketaylr> | maybe we need a resolution "RESOLVED RETARDED" |
| 17:15 | <jgraham> | Curiously I was going to suggest the same thing |
| 17:16 | <jgraham> | Although to be fair RESOLEVED: DON'T HIRE REPORTER AS C PROGRAMMER is more accurate |
| 17:16 | <TabAtkins_> | hahaha |
| 17:17 | <zewt> | that's a tag stackoverflow needs badly |
| 17:17 | <zewt> | "unhirable" |
| 17:17 | <zewt> | or at the very least, "doomed" |
| 17:55 | <TabAtkins_> | Urgh, tablelayout is such a horrible decisions. >_< |
| 17:55 | <TabAtkins_> | Also: Hixie, I apologize for submitting the winning table example CP. |
| 18:05 | <TabAtkins_> | Hmm, the spec doesnt' seem to define which actions will focus an element, beyond sequential focus navigation. |
| 18:05 | <TabAtkins_> | In specific, there's some incompatibility between browsers over whether clicking an <a href> focuses it. |
| 18:10 | <AryehGregor> | TabAtkins_, presumably the spec doesn't want to get too heavily into UI stuff. |
| 18:12 | <TabAtkins_> | That's what I suspect as well, but I have an internal developer complaining at me about it. ^_^ |
| 18:23 | <aho> | "FFS, the HTMLWG just decided to allow presentation tables as valid HTML." |
| 18:23 | <aho> | wtf? |
| 18:24 | <TabAtkins_> | See the decision on issue 130 |
| 18:25 | <aho> | got a link? |
| 18:25 | <TabAtkins_> | http://lists.w3.org/Archives/Public/public-html/2011Mar/0245.html |
| 18:26 | <aho> | ty |
| 18:29 | <AryehGregor> | Okay, so am I correct that when hg tries to merge something, it seems to be starting up vim, and then if I quit vim without saving because I have no interest in using it for merge resolution and just want conflict markers, it does some kind of braindead merge and destroys my work or something like that? |
| 18:30 | <AryehGregor> | Or is this somehow nondefault? |
| 18:31 | AryehGregor | tries setting merge = internal:merge, but really doesn't appreciate the "do some mysterious and probably destructive merge without actually asking me" |
| 18:31 | <AryehGregor> | I really hate hg. |
| 18:31 | <AryehGregor> | Ah, hg rollback works. |
| 18:31 | <AryehGregor> | Maybe. |
| 18:31 | <AryehGregor> | No, not really. |
| 18:31 | AryehGregor | restores from backup |
| 18:35 | <AryehGregor> | Hmm, maybe it was only the output file that conflicted, not the source . . . whatever. |
| 18:56 | <foolip_> | jgraham, are you around? |
| 19:40 | <AryehGregor> | Why did I think extractContents() and cloneContents() would be easy to spec after deleteContents()? They're way more complicated. |
| 19:40 | <AryehGregor> | On the bright side, it's improving my understanding of ranges a lot. |
| 19:41 | <AryehGregor> | (Although it's sad that ranges are that hard to understand.) |
| 19:46 | <hober> | just a reminder that http://www.w3.org/2002/09/wbs/40318/issue-56-objection-poll closes tomorrow |
| 19:46 | <TabAtkins_> | I have no idea which one I should care about. |
| 19:47 | <zewt> | secret issues? heh |
| 19:47 | <Hixie> | wow, the chairs finally made a completely wrong decision |
| 19:47 | <Hixie> | wonder what i'm supposed to do now |
| 19:47 | <TabAtkins_> | Fork the spec, finally? |
| 19:48 | <hober> | Hixie: which one? <table role=presentation>? |
| 19:49 | <Hixie> | the change from "Tables must not be used as layout aids" to "Tables should not be used as layout aids" |
| 19:50 | <zewt> | i've never really understood that--it doesn't make sense to me for specs to say what I can use something for, only what the feature does |
| 19:51 | <TabAtkins_> | Sure it does. If a feature can be fundamentally misused by an author unaware of the issues that make the misuse bad, the most useful path is to just disallow that use. |
| 19:53 | <TabAtkins_> | It's like disallowing people from putting important information in the content of a ::before element, except I think that CSS doesn't explicitly say MUST NOT (because we're somewhat allergic to using the word "must"). |
| 19:53 | <zewt> | but what does it even mean, if it's not even objectively testable? |
| 19:54 | <zewt> | it's fine to say "if you do this, some UAs may do something you don't expect and leave you with something you didn't want", but that should be implied from the requirements placed on the UA |
| 19:54 | <TabAtkins_> | Authors dont' read UA requirements. ^_^ |
| 19:55 | <zewt> | that's sort of the point, it's going to work, so people are going to do it |
| 19:56 | <zewt> | eg. it's not something that a validator can flag for people |
| 19:56 | <TabAtkins_> | Not an automatic validator, no. |
| 19:56 | <AryehGregor> | Hixie, if this encourages authors to put role=presentational on their presentational tables, I think it will be an excellent change. |
| 19:56 | <TabAtkins_> | That doesn't mean it can't be flagged manually, though. |
| 19:57 | <TabAtkins_> | AryehGregor: If this encourages authors to write more pages with presentational tables rather than using current and upcoming CSS layout techniques, it will be a horrible change. |
| 19:57 | <AryehGregor> | Also true. |
| 19:57 | <AryehGregor> | Hard to say which is going to be the bigger effect in practice. |
| 19:57 | AryehGregor | hasn't read the decision yet, though |
| 20:01 | <TabAtkins_> | One outcome only affects legacy pages (which aren't, in general, very likely to change), while the other affects pages that have not yet been created. We usually optimize for the latter, precisely because the former are unlikely to change en masse. |
| 20:02 | <AryehGregor> | I've seen a lot of templates on Wikipedia that use presentational tables. |
| 20:02 | <AryehGregor> | It'd be a bloody lot easier to add role=presentational than to rewrite them to not use tables. |
| 20:02 | <AryehGregor> | Particularly if they're protected, so only admins can edit them. |
| 20:03 | <AryehGregor> | More generally, if some site uses presentational tables, you're a lot more likely to get it fixed to use role=presentational than to get it fixed to not use tables. |
| 20:03 | <AryehGregor> | How about we say nested tables aren't conforming unless they all have role=presentational? |
| 20:03 | <AryehGregor> | Or all but the innermost, say. |
| 20:04 | <AryehGregor> | That would be a nice and concrete improvement, right? You could also just say they're not conforming period, but that would get fewer sites to change. |
| 20:06 | <Hixie> | (does saying role=presentational on a table even work, per ARIA? don't you have to set it on all the cells and rows and everything?) |
| 20:06 | <AryehGregor> | If it doesn't, wouldn't that be new information? |
| 20:07 | <Hixie> | one would assume the chairs actually checked that kind of thing before making this kind of decision |
| 20:07 | <Hixie> | so presumably not |
| 20:07 | <AryehGregor> | They only read what's submitted to them, right? |
| 20:08 | <Hixie> | if they only read what's sumitted, then them making decisions on the spec is irresponsible |
| 20:08 | <AryehGregor> | I think you're a couple years late in that judgment. |
| 20:08 | <Hixie> | but i doubt that they limit themselves |
| 20:08 | <Hixie> | that would be crazy |
| 20:09 | <AryehGregor> | Well, you could ask. |
| 20:11 | <Hixie> | i'm deep in video-conferencing edits right now |
| 20:11 | <Hixie> | but when i get to applying their decision, i'm sure i will be talking to them :-) |
| 20:11 | <Hixie> | i can't believe they just reverted 15 years of advocacy so casually |
| 20:13 | <zewt> | if they're making decisions without talking to the spec editor about them first, it's a pretty hopelessly broken system, heh |
| 20:14 | <AryehGregor> | The spec editor has a chance to comment. |
| 20:15 | <zewt> | "commenting" isn't the same as discussion, and from the fact that he seems borderline blindsided by this it doesn't seem like there was actual discussion, heh |
| 20:16 | <Hixie> | i'm not blindsided, they've been due to give a decision on this for months |
| 20:16 | <Hixie> | i'm just shocked at what they decided |
| 20:16 | <pesla> | Does that mean that any element with role=presentational can be used for layout purposes? :) |
| 20:16 | <Hixie> | i'm about to move the forums over from my account to a dedicated role account so zcorpan can manage them, so if they go down it's not hugely unexpected |
| 20:16 | <Hixie> | if all goes well though it should just transition smoothly |
| 20:18 | Hixie | presses the button |
| 20:25 | <Hixie> | holy cow |
| 20:25 | <Hixie> | i moved the forums to another user and NOTHING BROKE as far as i can tell |
| 20:25 | <Hixie> | sweet! |
| 20:26 | <zewt> | when nothing seems to break, that's when you start to get worried |
| 20:26 | <zewt> | the big, obvious breaks--those are the easy ones |
| 20:26 | <Hixie> | well i'm going offline for a few hours now, so expect the forums to catch fire momentarily! :-) |
| 20:26 | <Hixie> | bbl |
| 20:52 | <cying> | dear WG: what is the vendor prefix syntax for CSS *classnames*? |
| 20:52 | <cying> | is it ... -vendor-* ? |
| 20:52 | <cying> | i thought that's only for CSS properties... |
| 20:53 | <AryehGregor> | "classnames"? |
| 20:53 | <cying> | yeah |
| 20:53 | <cying> | like if a vendor wanted to have a set of class names for the general web to use... what would they specify that wouldn't clash? |
| 20:55 | <AryehGregor> | Vendors are not allowed to use class names. Only authors are. |
| 20:56 | <AryehGregor> | Well, I don't see that stated explicitly in the spec. |
| 20:56 | <AryehGregor> | But that's the general practice. |
| 20:56 | <AryehGregor> | Vendors who want to introduce features typically introduce attributes, they don't reuse the class attribute. |
| 20:57 | <AryehGregor> | Does this crash Opera 11 for everyone else too? http://aryeh.name/spec/dom-range/test/Range-extractContents.html |
| 20:58 | <zewt> | yeah. |
| 20:58 | <gsnedders> | AryehGregor: yes |
| 20:58 | <AryehGregor> | Yay. |
| 20:58 | <AryehGregor> | Want to have someone look into it? |
| 20:59 | <gsnedders> | Nah, let's just leave the crash bug unfixed! |
| 20:59 | <AryehGregor> | That would be sad, because then I'd have to figure out myself how to work around it. |
| 21:01 | <gsnedders> | Trying to create a comment, it would seem |
| 21:03 | <AryehGregor> | createComment() is crashing? |
| 21:04 | <gsnedders> | No, creating a comment because of some range thing |
| 21:05 | <AryehGregor> | Always happy to help you track down crash bugs. |
| 21:05 | <gsnedders> | extractContents/cloneContents somewhere |
| 21:07 | <gsnedders> | Whcih is unsurprising with what that is testing :) |
| 21:08 | <AryehGregor> | It's extractContents(). |
| 21:09 | <gsnedders> | Yeah, so it crashes when creating a comment node because of extractContents is not the most surprising of causes. |
| 21:12 | <AryehGregor> | Hardly a common case to extractContents() a range including comments, I guess. |
| 21:22 | <TabAtkins_> | cying: What Aryeh said. Classes are entirely a user-level extension mechanism. Vendors work in pseudo-classes and similar. |
| 21:23 | <cying> | TabAtkins_: hmmm i guess we don't want to recommend custom attributes though |
| 21:23 | <TabAtkins_> | cying: I'm missing context. What you are trying to do? |
| 21:24 | <cying> | TabAtkins_: i want to recommend additional hints people can add to their web pages, ala Instapaper adding a class "instapaper-ignore" to elements on a web page to ignore those elements |
| 21:24 | <TabAtkins_> | > |
| 21:24 | <cying> | TabAtkins_: (when instapaper performs readability on a page, it'll ignore those elements in the web page) |
| 21:24 | <TabAtkins_> | For what? |
| 21:24 | <cying> | so that an article's "readable subset" can be extracted out |
| 21:25 | <cying> | or, in our case: |
| 21:25 | <cying> | we want to mark an element in a web page that is meant to be the "byline" for an article... so we're considering asking publishers to add "flipboard-byline" to the classes for an element |
| 21:25 | <cying> | so: |
| 21:26 | <dglazkov> | what's up with forwarding emails from private lists? |
| 21:26 | <TabAtkins_> | This should be done through a standardization effort, if it's something that you want to do at the browser level. |
| 21:26 | <cying> | <span class="myformatting">Charles Ying</span> would become: |
| 21:26 | <cying> | <span class="myformatting flipboard-byline">Charles Ying</span> |
| 21:26 | <AryehGregor> | dglazkov, probably shouldn't happen, I guess? |
| 21:26 | <dglazkov> | cant' the author just resend it? :) |
| 21:26 | <zewt> | dglazkov: the author may not be on the list--having to subscribe just to repost one message is a pain |
| 21:27 | <AryehGregor> | (without the author's permission, that is) |
| 21:27 | <TabAtkins_> | cying: If you're trying to annotate the page with additional semantic information, this should be standardized. |
| 21:27 | <cying> | TabAtkins_: understood, we don't really need it to be at the browser level, but wanted to try to make something along the same thinking as the spec community |
| 21:27 | <TabAtkins_> | I dont' necessarily mean through HTML, though - microformats sounds like a good avenue to pursue this in. |
| 21:27 | <cying> | TabAtkins_: is there an existing effort for annotating pages? |
| 21:27 | <cying> | i see |
| 21:27 | <cying> | microformats can get tricky for some of our publishers, we'll need something simpler |
| 21:28 | <TabAtkins_> | Annotating a page with hAtom isn't difficult, and it provides pretty good structure for extracting. |
| 21:29 | <cying> | TabAtkins_: ah! got it, that's more along the lines of what we're looking for |
| 21:29 | <TabAtkins_> | The point is that you should *not* unilaterally create an application-specific annotation mechanism that you want to deploy to the web. |
| 21:29 | <cying> | TabAtkins_: thanks! |
| 21:30 | <TabAtkins_> | No problem. ^_^ |
| 21:30 | <cying> | TabAtkins_: we're trying very hard not to. we really dislike having to say "flipboard-*" for class names |
| 21:37 | <dglazkov> | is daniel glazman visiting these parts of the world? |
| 21:37 | <TabAtkins_> | He's gone back to france now. |
| 21:37 | <dglazkov> | :) |
| 21:38 | <dglazkov> | I mean this channel |
| 21:38 | <TabAtkins_> | Oh, that wasn't obvious. ^_^ No, he doesn't do this channel. You may be able to raise him on irc.w3.org#css |
| 21:45 | <jgraham> | foolip_: I am somewhat around now |
| 21:46 | <dglazkov> | heycam: great response |
| 21:46 | <heycam> | dglazkov, thanks |
| 21:46 | <heycam> | I think people are reasonably happy with things like SVG & MathML having dedicated syntax in text/html, as well as the XML syntax |
| 21:47 | <heycam> | so I don't think it is unreasonable to do the same with XBL (or whatever the end solution is) |
| 21:48 | <dglazkov> | heycam: yup |
| 21:49 | <dglazkov> | heycam: I decided we should call it HTML5 Modularity- enabling Dujibobs, or HTML5MED |
| 21:49 | <heycam> | ha |
| 21:50 | heycam | takes his html5 meds |
| 21:50 | <zewt> | what the |
| 21:51 | <zewt> | my xhr progress-events form that works in chrome 9 doesn't work in FF4 :| time to find out why |
| 21:52 | <jgraham> | "The HTML serialization of a binding won't be usable in a UA not suppporting HTML" well duh... |
| 21:52 | <zewt> | heh user error ... sort of |
| 21:52 | <heycam> | "don't do that then" |
| 21:53 | <heycam> | although if you're thinking of the case where you want to use bindings someone else has written, and they are written in an HTML document... |
| 21:53 | <zewt> | typing a hostname in the address bar in FF will complete based on title before hostname, so when I typed "foo" to load "foo.com" (real site) it loaded 10.0.0.1 with title "foo site" and I didn't notice :| |
| 21:53 | jgraham | isn't thinking of any case |
| 21:53 | jgraham | is just finding glazou's argument silly |
| 21:53 | <zewt> | address bars try to be too clever for anyone's good these days |
| 21:53 | <gsnedders> | AryehGregor: http://pastebin.com/AgRRbWXJ |
| 21:53 | <foolip_> | jgraham, just wanted to ask you about http://code.google.com/p/html5lib/issues/detail?id=178 but I guess you've gotten email about it by now |
| 21:54 | <gsnedders> | AryehGregor: The important point is that the range ends at offset zero into the comment |
| 21:54 | <AryehGregor> | gsnedders, cool. |
| 21:54 | <jgraham> | sicking: So what is the state of the hsitory API stuff? Do you have / expect byt-in from WebKit on these changes? |
| 21:55 | <TabAtkins_> | Okay, I just plain can't watch flash video in Chrome 10 any more. Dammit. |
| 21:55 | <jgraham> | foolip_: Looking |
| 21:55 | <jgraham> | TabAtkins_: "feature" |
| 21:55 | <zewt> | heh |
| 21:56 | <TabAtkins_> | jgraham: Hah, I wish. If it was a feature it wouldn't crash the renderer. |
| 21:56 | <jgraham> | TabAtkins_: It's called "being taught a lesson" |
| 21:56 | <zewt> | teach lessons after html video is feature complete :P |
| 21:57 | <AryehGregor> | gsnedders, okay, I commented that test out. |
| 21:57 | <TabAtkins_> | Or at least after Youtube does its total conversion. |
| 21:57 | <zewt> | until we have programmatic fullscreen, and UAs can actually scale video to fullscreen without dropping to a slideshow |
| 21:57 | <zewt> | (at least) |
| 21:58 | <zewt> | maybe the latter has improved lately, havn't checked |
| 22:03 | <dglazkov> | TabAtkins_: you should totally yell at someone. You're in the right office :) |
| 22:03 | <TabAtkins_> | Indeed. |
| 22:06 | <TabAtkins_> | All right, yelling is done. |
| 22:06 | <AryehGregor> | gsnedders, okay, I sanity-checked Opera's results and now uncommented the line, so Opera crashes on the test again. Not really fair to remove tests just because someone crashes on them. But I left a comment in the source explaining which line you have to comment out for it to work. |
| 22:10 | <AryehGregor> | Hurrah, extractContents() specced and tested. |
| 22:10 | <AryehGregor> | Now for cloneContents(). |
| 22:10 | <AryehGregor> | Should be easy after extractContents(). And I mean it this time. |
| 22:11 | <AryehGregor> | Since its functionality is basically a subset of extractContents()'s. |
| 22:12 | <dglazkov> | copy/paste time! :) |
| 22:12 | <zewt> | itym cloneContents() time |
| 22:16 | <AryehGregor> | I considered writing all three methods' specs in the same algorithm with variations called out, but it wound up being too messy. |
| 22:20 | <gsnedders> | AryehGregor: The expected result for what I pastebined is an empty comment, right? |
| 22:21 | <AryehGregor> | Let's see: http://html5.org/specs/dom-range.html#dom-range-extractcontents |
| 22:22 | <AryehGregor> | Contained nodes would be empty, first partially contained child is null, last partially contained child is the comment. |
| 22:22 | <AryehGregor> | So yeah, you should clone it and set the data to the empty string. |
| 22:22 | <AryehGregor> | Per spec. |
| 22:23 | <AryehGregor> | Which admittedly I just made up. |
| 22:23 | <AryehGregor> | But it matches Gecko and WebKit. |
| 22:25 | <gsnedders> | AryehGregor: And if it started at div.firstChild it should return an empty DocumentFragment? |
| 22:25 | <AryehGregor> | Yes, that's what Gecko and WebKit do. Opera clones an empty node in this case too. |
| 22:25 | <AryehGregor> | Which possibly makes more sense. |
| 22:26 | <AryehGregor> | But too late for making sense. |
| 22:26 | <gsnedders> | Yeah, I know we make an empty node in that case too… because we crash in that case too :P |
| 22:26 | <AryehGregor> | Er, well. |
| 22:26 | <gsnedders> | (Trying to create the empty node) |
| 22:26 | <AryehGregor> | Ah, I see. |
| 22:26 | <AryehGregor> | But for text nodes you succeed. |
| 22:26 | <AryehGregor> | Didn't test PIs. |
| 22:26 | <gsnedders> | And for CDATASections we do too. |
| 22:27 | <AryehGregor> | CDATASections don't exist in Web DOM Core-land. |
| 22:27 | <AryehGregor> | I don't know why, since browsers seem to implement them. |
| 22:27 | <gsnedders> | I don't understand how we don't crash with CDATASections, but we don't. :P |
| 22:27 | <AryehGregor> | But the DOM Range spec doesn't consider them, because it depends on DOM Core, and DOM Core says they don't exist. |
| 22:28 | <gsnedders> | PIs would be interesting to test too, IMO |
| 22:28 | <AryehGregor> | I do test PIs. |
| 22:28 | <gsnedders> | Ah, okay, just in our case for this you didn't test PIs. |
| 22:28 | <AryehGregor> | I have at least three tests that involve PIs. |
| 22:30 | <AryehGregor> | data:application/xhtml+xml,<html xmlns="http://www.w3.org/1999/xhtml"><body><![CDATA[<span>foo</span>]]><script>alert(document.querySelector("body").firstChild);</script></body></html>; |
| 22:30 | <AryehGregor> | That alerts a CDATASection. |
| 22:31 | <AryehGregor> | Why does DOM Core not acknowledge them? |
| 22:31 | <AryehGregor> | annevk, ^? |
| 22:31 | <TabAtkins_> | Hahaha, "Electron Band Structure in Germanium, My Ass": http://pages.cs.wisc.edu/~kovar/hall.html |
| 22:33 | <gsnedders> | AryehGregor: IIRC, mine/zcorpan's argument was there was no good reason why they can't just be Text nodes |
| 22:33 | <charlvn> | TabAtkins_: now that's my kind of research! :P |
| 22:42 | <jgraham> | TabAtkins_: That is the reason to give up experimental physics |
| 22:43 | <jgraham> | Or rather was my reason |
| 22:43 | <jgraham> | Well in particular the fact that I sucked at it |
| 22:43 | jgraham | is physically incapable of any task involving a soldering iron |
| 22:44 | jgraham | is not happy about this as there are many useful things that can be acomplished using a soldering iron |
| 22:45 | jgraham | has no particular evident handicap that should lead to this particular problem, but nevertheless it exists |
| 22:45 | <dglazkov|away> | at ths point, the appropriate response is MONKEYPANTS |
| 22:45 | <dglazkov|away> | it's appropriately nonsensical |
| 22:54 | <dglazkov> | TabAtkins <3 |
| 23:02 | <TabAtkins_> | Does anyone else see my response on the <canvas src> thread which I just posted? |
| 23:02 | <TabAtkins_> | The public-html list just autoresponded me in a way that suggests it forget I'm a member. |
| 23:03 | <heycam> | TabAtkins_, yes: http://www.w3.org/mid/AANLkTi=8rxN8gVzYf4wU1OP6db82tjR+zjSMDpRNqt_=@mail.gmail.com |
| 23:03 | <TabAtkins_> | heycam: Okay, cool. So I'll just ignore this as the listdaemon being crazy. |
| 23:03 | <heycam> | but see you've CCed public-html-request too, maybe that was the cause of the mail back? |
| 23:03 | <TabAtkins_> | Oh, wow, I did? Who put that in there? That doesn't even make sense. |
| 23:04 | <heycam> | yeah I have no idea why that gets in peoples' CC lists sometimes |
| 23:12 | <AryehGregor> | gsnedders, are browsers planning to actually make them text nodes, though? |
| 23:12 | <gsnedders> | AryehGregor: Dunno |
| 23:12 | <AryehGregor> | It would make more sense to treat them like entities, and merge them into adjacent text nodes when deserializing the XML. Not make them text nodes themselves. |
| 23:14 | <AryehGregor> | What specification defines how to parse XML into a DOM? Does XML 1.0 itself somehow define that? |
| 23:14 | <heycam> | agree |
| 23:14 | <AryehGregor> | It doesn't mention "DOM" anywhere. |
| 23:14 | <AryehGregor> | Oh, wait. |
| 23:14 | <AryehGregor> | I see, HTML seems to, at least for XHTML. |
| 23:14 | <AryehGregor> | No, it sort of defers to other specs in a vague fashion. |
| 23:15 | <gsnedders> | AryehGregor: XML Infoset |
| 23:16 | <gsnedders> | And then somewhere maps the Infoset to the DOM |
| 23:16 | <AryehGregor> | Fun. |
| 23:16 | <AryehGregor> | Is anyone planning on actually speccing how to parse XML into a DOM without CDATASection, or is DOM Core just going to pretend they don't exist without defining what to do with them? |
| 23:17 | <AryehGregor> | Because it makes more sense to reflect reality here if no one has specific plans to change, IMO. |
| 23:20 | <Hixie> | cying: there's no particular syntax for custom class names, it's just a microformat. Best bet is to go to the microformats community and put forward your use case and see what they suggest. |
| 23:20 | <Hixie> | cying: ("it has to be really simple" being part of your use case) |
| 23:20 | <Hixie> | cying: i don't see anything wrong with class="byline" being sufficient, though |
| 23:21 | <cying> | Hixie: thanks... yeah, class="byline" is okay... but we want a bit more namespacing as to not conflict with most common classes |
| 23:21 | <cying> | Hixie: i think that's the path we'll take |
| 23:22 | <Hixie> | what's wrong with conflicting with class="byline"? |
| 23:22 | <Hixie> | it's not like people will have used it for anything but a byline :-) |
| 23:24 | <dglazkov> | Hixie: dhyatt (and I) want to change the spec: https://bugs.webkit.org/show_bug.cgi?id=56001#c9. Do I send mail to whatwg? File a bug? Wait for things to magically happen on its own? |
| 23:24 | <Hixie> | please hold |
| 23:24 | <Hixie> | looking... |
| 23:25 | <Hixie> | if you want to change that you should mail the list explaining the reason for it to be changed |
| 23:25 | <dglazkov> | k |
| 23:25 | <Hixie> | (what's the reason?) |
| 23:25 | <dglazkov> | can't do it reasonably in WebKit and still allow user styling of controls |
| 23:25 | <Hixie> | "it's hard" is a lame reason |
| 23:25 | <Hixie> | authors are more important than implementors |
| 23:26 | <TabAtkins_> | How about "It's impossible in pure CSS"? |
| 23:26 | <dglazkov> | didn't say it's hard. can't do it != it's hard |
| 23:26 | <Hixie> | of course you can do it :-) |
| 23:26 | <dglazkov> | :) |
| 23:26 | <Hixie> | just define a new appearance value that automatically senses the direction and renders it appropriately |
| 23:26 | <Hixie> | what's the problem here |
| 23:27 | <TabAtkins> | "Renders it appropriately" means that it's being done magically by the browser, and can't be done by the user. |
| 23:27 | <dglazkov> | how does a user-styled control do it? |
| 23:28 | <dglazkov> | TabAtkins: I think we downed Hixie |
| 23:28 | <dglazkov> | :) |
| 23:28 | <Hixie> | if the author wants to change the rendering, they use xbl, just like any other form control |
| 23:29 | <Hixie> | the whole point of this control is that they get platform-native rendering and don't have to override anything |
| 23:29 | <TabAtkins> | We don't do platform-native rendering. ^_^ |
| 23:29 | <dglazkov> | Hixie: that's not the way it works now. There's lots of uses in the wild where peeps put -webkit-appearance:none and style their controls already |
| 23:30 | <Hixie> | css doesn't support styling <meter> manually anyway, whether it's vertical, horizontal, or both. |
| 23:30 | <Hixie> | it's like <select>'s drop-down, there's no way to style it from css. |
| 23:30 | <dglazkov> | Hixie: there is in WebKit |
| 23:30 | <Hixie> | demo page? |
| 23:31 | dglazkov | builds a demo page |
| 23:33 | <dglazkov> | http://jsfiddle.net/TmRPq/ |
| 23:34 | <Hixie> | oh i thought you meant for <select> |
| 23:34 | <dglazkov> | Hixie: that would be great, actually, but no :) |
| 23:35 | <dglazkov> | at this point, we have two choices: 1) not implement size-sensing in WebKit and 2) change the spec to allow explicit sizing |
| 23:35 | <Hixie> | ok well for <meter> you've already solved the problem. Just change "::-webkit-meter-horizontal-bar" to "::-webkit-meter-bar", and dynamically determine the stacking direction. |
| 23:35 | <dglazkov> | besides, auto sizing is not necessary what you need. |
| 23:35 | <TabAtkins> | That doesn't let you, for example, use a gradient for the bar. |
| 23:36 | <TabAtkins> | (Since you need to know the direction to construct the right gradient.) |
| 23:36 | <dglazkov> | you might want a fat, short meter |
| 23:36 | <dglazkov> | like the old-school radio lamp ones |
| 23:37 | <TabAtkins> | Huh. My editor is highlighting 'import' like it's a reserved word in PHP. The googles don't tell me anything about this, though. AryehGregor, you know anything? |
| 23:38 | <Hixie> | TabAtkins: you know the direction, since you set the dimensions too |
| 23:38 | <gsnedders> | TabAtkins: It isn't |
| 23:38 | <AryehGregor> | TabAtkins, pretty sure it's not. |
| 23:38 | <Hixie> | dglazkov: show me one page anywhere that actually does that |
| 23:38 | <TabAtkins> | Okay, thanks. My syntax highlighter is just dumb. |
| 23:38 | <AryehGregor> | http://php.net/manual/en/reserved.php |
| 23:39 | <Hixie> | (if you really want to support a fat meter, just have three appearance values: -webkit-meter, -webkit-meter-horizontal, -webkit-meter-vertical) |
| 23:39 | <dglazkov> | Hixie: appearance is not going to cut it if I want to style it |
| 23:41 | <Hixie> | you need 'appearance' and the pseudos, sure |
| 23:41 | <dglazkov> | Hixie: here's a page: http://jsfiddle.net/TmRPq/2/ |
| 23:41 | <dglazkov> | Hixie: why go into all the trouble? |
| 23:41 | <Hixie> | because most people won't want to style it and because a fat meter is dumb |
| 23:41 | <Hixie> | it's the right thing to do |
| 23:42 | <dglazkov> | Hixie: I think it's too early to tell if most people don't want to style it |
| 23:42 | <Hixie> | no it's not |
| 23:42 | <Hixie> | look at all other controls |
| 23:42 | <dglazkov> | :) |
| 23:42 | <Hixie> | most people don't style them |
| 23:42 | <Hixie> | anyway i'm not saying don't support styling |
| 23:42 | <Hixie> | i'm saying: |
| 23:42 | <Hixie> | * support styling |
| 23:42 | <Hixie> | * by default orient sanely |
| 23:42 | <Hixie> | * allow override of orientation |
| 23:43 | <Hixie> | this seems to support everything you've mentioned and everything i've mentioned |
| 23:43 | <dglazkov> | how would I override orientation? |
| 23:43 | <Hixie> | <Hixie> (if you really want to support a fat meter, just have three appearance values: -webkit-meter, -webkit-meter-horizontal, -webkit-meter-vertical) |
| 23:43 | <AryehGregor> | Hixie, all existing form controls are meant to allow the user to input things, not present information to the user. |
| 23:43 | <AryehGregor> | I think that makes a difference to how likely people are to want to style them. |
| 23:43 | <dglazkov> | can you help me with a bit of code? |
| 23:44 | <dglazkov> | Hixie: I don't understand what you mean |
| 23:44 | <dglazkov> | if I want to style controls, I have to set apprearance: none |
| 23:45 | <dglazkov> | especially if there platform-specific styling |
| 23:45 | <dglazkov> | (and since we're arguing about styling controls, I think you'd be surprised how many sites actually _do_ style controls) |
| 23:46 | <dglazkov> | especially considering there are entire libraries dedicated to that |
| 23:46 | <Hixie> | how do you control the direction today? |
| 23:48 | <dglazkov> | Hixie: it's done in a wrong way today for meter and progress. We use -webkit-appearance: slider-vertical for input[type=range] |
| 23:48 | <dglazkov> | once you've made it vertical, you can't apply user styling to it |
| 23:48 | <dglazkov> | it sucks |
| 23:48 | <Hixie> | ok so here's a proposal: |
| 23:48 | <Hixie> | for the default rendering, have -webkit-appearance: meter / slider / progress; |
| 23:49 | <Hixie> | once you set -webkit-appearance: none, get the direction from -webkit-direction: horizontal / vertical |
| 23:49 | <dglazkov> | that's what I suggested in https://bugs.webkit.org/show_bug.cgi?id=56001#c1 |
| 23:50 | <Hixie> | then you have a bunch of pseudos for the various parts, like ::-webkit-meter-bar, ::-webkit-meter-high, ::-webkit-slider-thumb, whatever |
| 23:50 | <dglazkov> | or nearly |
| 23:50 | <Hixie> | so where's the problem |
| 23:51 | <dglazkov> | Hyatt thinks box-sensing is a dumb idea :) |
| 23:51 | <dglazkov> | you should talk to him |
| 23:51 | <Hixie> | hyatt is a big boy, he can argue his own thoughts if he wants the spec changed |
| 23:51 | <dglazkov> | :) |
| 23:55 | <dglazkov> | Also: I think that adding this "magic" to controls is a bad idea for a whole different reason: it's not possible with just CSS. |
| 23:55 | <dglazkov> | dglazkov: and I intuitively hate "magic" in the platform |
| 23:55 | <TabAtkins> | Now you're talking to yourself? |
| 23:55 | <zewt> | that's you, by the way |
| 23:55 | <dglazkov> | :D |
| 23:55 | <dglazkov> | sorry |
| 23:56 | <zewt> | zewt: this guy's losing it |
| 23:56 | <dglazkov> | I would rather see less magic in the platform, moving to a place where you could concievably "explain" all built-in HTML elements with CSS. |
| 23:56 | <AryehGregor> | URLs starting with \\ in Windows are network shares or something, right? |
| 23:57 | <zewt> | among other things |
| 23:57 | <AryehGregor> | Is there some standard way to express those in URLs? Like replace the initial \\ with smb:// or something? |
| 23:57 | <AryehGregor> | The URL is specifically: \\eshel.campus.ad.bgu.ac.il\BW-Students |
| 23:59 | <zewt> | file://///host/path in firefox (5) |
| 23:59 | <zewt> | (had to squint to be sure I wasn't going crazy, heh) |
| 23:59 | <AryehGregor> | Heh. |