| 00:07 | <othermaciej> | does anyone know if XAML has a an immediate-mode graphics API> |
| 00:07 | <othermaciej> | ? |
| 00:21 | <alp> | othermaciej: xaml is just the markup, but afaik wpf is entirely retained mode |
| 00:22 | <othermaciej> | looks like it to me too, so far as I can tell from the docs |
| 00:24 | othermaciej | wonders how custom classes do their drawing |
| 00:26 | <othermaciej> | aha, there is direct rendering |
| 00:26 | <othermaciej> | via OnRender |
| 00:28 | <alp> | is the consensus on geolocation currently use navigator.getGeolocation()? i'm going to hack up support for this in the n810 tablet browser |
| 00:29 | <othermaciej> | no idea |
| 00:29 | <alp> | maybe someone who was involved in this thread knows, http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009626.html |
| 00:30 | <othermaciej> | I don't know if anyone implements it, might be worth asking Opera and/or Nokia folks |
| 02:19 | <jruderman> | Hixie: have you been following the discussions in m.d.a.firefox about <a ping>? |
| 02:19 | <jruderman> | Hixie: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/a8469770c8f9fe52 |
| 02:38 | <Hixie> | i was aware of the discussion but haven't followed it |
| 02:38 | <Hixie> | anything i should be aware of? |
| 02:48 | <roc> | "UI for pings sucks" |
| 02:53 | <othermaciej> | you could do a status bar effect, that would be sufficient for the sort of person likely to be a privacy weenie and unobstrusive otherwise |
| 02:53 | <othermaciej> | that's what I would do if I wanted to implement ping |
| 02:54 | <othermaciej> | (if you have the status bar off, or don't look, you don't even know where the link will go, so why would you care that it pings an extra URL?) |
| 02:59 | <Hixie> | yeah i didn't understand the arguments against the status bar thing |
| 02:59 | <Hixie> | i don't see how it sucks any more than the link UI in the first place |
| 03:02 | <othermaciej> | I did not read the arguments in detail, that's just my immediate thought |
| 03:02 | <roc> | a privacy weenie might as well just disable ping altogether |
| 03:03 | <roc> | maybe the sort of person exists who obsessively checks the status bar every time they click on a link |
| 03:03 | <roc> | I'd like to see an existence proof before implementing UI for them |
| 03:03 | <roc> | (and in Firefox of course they could have their own special extension) |
| 03:04 | <othermaciej> | my conclusion is mostly that "ping" is not useful enough to implement |
| 03:04 | <othermaciej> | the main benefit is that it potentially gives users more info |
| 03:04 | <othermaciej> | but most users won't care |
| 03:05 | <othermaciej> | roc: I tend to look at the status bar before clicking blog links, though out of curiosity more than anything |
| 03:05 | <othermaciej> | I don't always look though |
| 03:07 | <othermaciej> | I guess <a ping> has the side effect that if sites use it, you get to see the real target URL in mouseover feedback |
| 03:07 | <othermaciej> | not the tracking redirect URL |
| 03:08 | <othermaciej> | the question is whether any sites will use it |
| 03:08 | <roc> | I think it's useful to implement. a) it's supposed to yield faster navigation than going through a redirect, b) you get the real URL on "copy link location" instead of some redirect URL, c) if sites start using it then people can disable it to get privacy benefits |
| 03:09 | <othermaciej> | I think all of those are contingent on "if sites start using it" |
| 03:09 | <roc> | most features are :-) |
| 03:09 | <othermaciej> | the more people disable it, the less sites are inclined to use it |
| 03:09 | <othermaciej> | well, some can give significant benefits only if relatively few sites use it |
| 03:10 | <roc> | if we ship it enabled, almost no-one will disable it |
| 03:10 | <othermaciej> | but certainly every feature should consider transition costs to using it |
| 03:10 | <jwalden> | get Google to promise to use it, and maybe I'd go for it |
| 03:10 | <othermaciej> | some sites get upset that Firefox lets you do ad blocking through extensions (not even the default UI) |
| 03:10 | <othermaciej> | some sites have crazy counter-measures for pop-up blocking even though it is not on by default for the majority of browser users |
| 03:10 | <roc> | yes, well, some sites are run by morons |
| 03:10 | <jwalden> | (instead of their current sucky redirect-URL-that-you-can-copy approach) |
| 03:11 | <othermaciej> | and "ping" has no story for fallback in browsers that don't support it |
| 03:11 | <othermaciej> | unlike things like <canvas> and <video> |
| 03:11 | <roc> | I "heard" that major search sites are keen on using <ping> because of the usability speedup from cutting the redirect out of the equation |
| 03:12 | <othermaciej> | for ad links? |
| 03:12 | <roc> | the fallback story for <canvas> and <video> is in reality quite weak. |
| 03:12 | <jwalden> | tangible benefits for the user are the only way to sell it -- that's the one I see working |
| 03:12 | <othermaciej> | I doubt search engines would use it for ad links, since then they would undercount the number of ad hits |
| 03:12 | <othermaciej> | which loses them money |
| 03:12 | <roc> | I think the idea was to track which search results users click on |
| 03:12 | <othermaciej> | (until most browsers support it, they would *vastly* undercut the number of ad hits) |
| 03:13 | <othermaciej> | ah |
| 03:14 | <jwalden> | depends how cheap user-agent-specific behavior is -- probably pretty cheap |
| 03:15 | <othermaciej> | might be useful for cases where lossy data is acceptable |
| 03:15 | <othermaciej> | anyway, I think either no UI or status bar indicator would be a reasonable form of the feature |
| 03:16 | <othermaciej> | I would lean towards status indicator since you lose the ability to see that the URL is some weird redirect thing with <a ping> but I don't think that is a very strong argument |
| 03:17 | <roc> | I think sites have to care enough to UA-sniff. Hopefully some will. We'll have to ship it and hope, like a lot of other things we've done |
| 03:17 | <othermaciej> | I specifically don't think the UI for ping needs to be any better than the UI for seeing where a link will go before clicking it |
| 03:17 | <othermaciej> | <video> could be used without UA-sniffing |
| 03:17 | <othermaciej> | and UA-sniffing is a bad practice |
| 03:18 | <othermaciej> | any fallback story that depends on UA sniffing is weak |
| 03:19 | <roc> | got a better idea for this situation? |
| 03:19 | <roc> | maybe standardize a redirect URL format and have "ping" automatically re-directize the URL :-) |
| 03:19 | <roc> | er |
| 03:19 | <roc> | un-redirectize |
| 03:29 | <jwalden> | redirect://site.com/redirector?http://url-to-visit/ |
| 03:29 | <jwalden> | so basically feed: all over again |
| 03:30 | <roc> | no |
| 03:30 | <jwalden> | er |
| 03:30 | <jwalden> | yeah, that's wrong |
| 03:30 | <jwalden> | blah, this hurts my head |
| 03:32 | <roc> | more like <a ping="pings.example.com" href="http://pings.example.com/redirect?http://mozilla.org">; and we guarantee that "ping", if supported, will strip off everything up to and including the first ? |
| 03:32 | <roc> | well, that's kinda wrong but that's the idea |
| 03:32 | <roc> | but that's actually a stupid idea |
| 03:32 | <roc> | so never mind |
| 03:34 | <othermaciej> | roc: ah, interesting |
| 03:35 | <othermaciej> | roc: that certainly has better fallback behavior, though still not sure that would drive more adoption |
| 03:35 | <othermaciej> | this is really a case where we need to ask content authors who do tracking what they think |
| 03:37 | <roc> | my understanding is that this was driven by content authors |
| 03:38 | <roc> | the problem with my idea is that it leaves the HREF busted |
| 03:38 | <roc> | for "Copy Link Location" etc |
| 03:39 | <roc> | oh, I suppose that for "ping"-supporting browsers, Copy Link Location and other UI features could auto-strip the URL |
| 03:39 | <roc> | as well |
| 03:40 | <roc> | adds complexity :-( |
| 03:51 | <Hixie> | yeah ping="" was basically designed by google to handle the problems that google has with the currently available options (and believe me, google is an _expert_ at how to do this kind of stuff) |
| 03:53 | <Hixie> | the biggest problems with that state of the art, from google's point of view, are lack of user privacy options (disabling), redirect slowness (which can be avoided with some browsers by abusing some bugs, but that sucks), and the transparency issue |
| 04:28 | <jruderman> | i hadn't thought of the "which search results did the user click?" use case, but it makes a lot of sense, given that google has been trying to do that for a while (presumably to improve search results rather than for any nefarious purpose) |
| 04:30 | <jruderman> | Hixie: i thought beltzner's posts in that thread were especially good |
| 04:30 | <jruderman> | Hixie: do you have a suggestion for what the enable-ping checkbox label should be? :) |
| 04:32 | <Hixie> | what did beltzner propose? |
| 04:32 | <Hixie> | [x] Allow sites to track which links you click on |
| 04:33 | <roc> | the problem with that is that even when you clear it, sites can still track which links you click on |
| 04:35 | <Hixie> | sites can still animate images even when animated images are disabled |
| 04:35 | <Hixie> | so what? |
| 04:35 | <roc> | this is true |
| 04:36 | <roc> | but we don't seem to have that pref in Firefox anymore :-) |
| 04:37 | <roc> | so I guess you need to think of another example |
| 04:37 | <Hixie> | cookies and flash |
| 04:38 | <Hixie> | but my point is just that the pref doesn't have to be pedantically correcty |
| 04:38 | <Hixie> | correct, even |
| 04:38 | <roc> | I guess the problem is that it's not even close |
| 04:38 | <Hixie> | it's close enough |
| 04:38 | <roc> | since at least initially clicking that box will have no effect on anything |
| 04:39 | <Hixie> | [ ] Enable out-of-band declarative link tracking |
| 04:39 | <Hixie> | s/link/click/ |
| 04:40 | <Hixie> | but personally i think "Allow sites to track which links you click on" is fine |
| 04:40 | <roc> | [ ] I trust Google |
| 04:40 | <Hixie> | or that |
| 04:40 | <Hixie> | though actually that's more misleading, imho |
| 04:41 | <roc> | I was joking, sorry |
| 04:41 | <Hixie> | since if you didn't trust google to use the track data ethically, you wouldn't trust google to use ping= in the first place |
| 04:41 | <Hixie> | oh i know :-) |
| 04:41 | <Hixie> | but even as a joke i don't think it works :-) |
| 05:06 | <jwalden> | [ ] Whatever |
| 05:06 | <jwalden> | none of the proposed phrasings are clear enough to work without needing to refer to help documentation |
| 05:12 | <othermaciej> | "Allow sites to track which links you click on" seems reasonable, although it makes the feature sound scarier than it is |
| 06:28 | <mpt> | s/Allow (.+) to (.+)/Let \1 \2/g |
| 06:29 | <mpt> | But it still fails the "...or what?" test |
| 06:29 | <mpt> | i.e. you can't tell, by reading it, why you'd want to check it |
| 06:30 | <mpt> | (or uncheck it) |
| 06:38 | <Hixie> | mpt: how would you phrase it? |
| 06:46 | <jwalden> | accuracy, clarity, non-tinfoil-hat-inducing -- pick two |
| 06:46 | <jwalden> | actually, make that second understandability |
| 06:50 | <Hixie> | to be honest i would target the pref at the tinfoil induced |
| 06:50 | <Hixie> | they're the only ones who will really care, based on my experience |
| 06:50 | <Hixie> | for all the cries about privacy -- and i agree that privacy is important -- few users seem to actually care in practice |
| 06:51 | <Hixie> | it's those who do care who should be able to turn it off easily |
| 07:19 | <othermaciej> | if I were designing the UI for Safari my recommendation would probably be no pref setting at all |
| 07:29 | <mpt> | Hixie, I don't think there's any good way to phrase it without referring to the specific HTML attribute (and therefore delving into geekitude), because it controls only one of the ways by which a Web site can track your clicks |
| 07:29 | <Hixie> | mpt: possibly |
| 07:29 | <mpt> | To go back to your animated images example, in my dream browser that checkbox would control GIFs *and* Flash *and* JavaScript src-changes |
| 07:30 | <Hixie> | mpt: and <canvas> painting and DOM manipulation on a timer and meta refresh in an iframe? |
| 07:30 | <mpt> | probably :-) |
| 07:30 | <Hixie> | othermaciej: unfortunately that removes one of the main reasons to do it (though not all of the reasons that benefit the user, it must be said) |
| 07:31 | <Hixie> | mpt: that would be a very confusing pref |
| 07:31 | <othermaciej> | Hixie: I don't think "privacy extremists can turn it off" is a very good reason to do anything |
| 07:31 | <othermaciej> | at least, so far as Apple products go |
| 07:31 | <Hixie> | fair enough |
| 07:32 | <othermaciej> | I do think |
| 07:32 | <othermaciej> | "you can see the real link target" |
| 07:32 | <othermaciej> | is a good reason |
| 07:32 | <othermaciej> | (to the extent that seeing the link target is interesting at all, which it is somewhat) |
| 07:32 | mpt | realizes he's not saying anything he didn't already say in October 2005 |
| 07:33 | <Hixie> | i think the reduced latency is the second most important reason (the first being the "option for privacy extremists"), at least from google's perspective |
| 07:34 | <othermaciej> | from google's perspective, can't it have its own pref? |
| 07:34 | <Hixie> | (we already handle showing the right uri, by changing the uri at the last second when the user follows the link) |
| 07:34 | <Hixie> | well, the target audience likely isn't logged in |
| 07:34 | <othermaciej> | (though I guess privacy extremists wouldn't want to let google set a cookie) |
| 07:34 | <Hixie> | right |
| 07:35 | <Hixie> | there are a number of reasons to do this beyond just the privacy angle, of course |
| 07:35 | <Hixie> | latency, ui, reliability, etc |
| 07:35 | <othermaciej> | it might be reasonable to restrict it only to be able to ping the host that served the page |
| 07:36 | <Hixie> | that actually fails to address some of google's most important occurances of click tracking |
| 07:36 | <Hixie> | sadly |
| 07:36 | <othermaciej> | similar to the default cookie policy in Safari |
| 07:36 | <Hixie> | (e.g. adsense) |
| 07:37 | <othermaciej> | would adsense be ok with a form of click tracking that you could turn off? |
| 07:38 | <Hixie> | users come above profits |
| 07:38 | <Hixie> | so yes |
| 07:39 | <Hixie> | (obviously, that might change if a browser defaulted to disabling it) |
| 07:39 | <Hixie> | frankly we have bigger problems with false reported hits than false unreported hits |
| 07:39 | <othermaciej> | so you wouldn't want a browser to ship with the "ping every click counter [ 10 ] times" pref? |
| 07:40 | <mpt> | Even assuming this was a good idea, it looks to me like it would be a tragedy of the commons |
| 07:40 | <othermaciej> | tragedy of the commons? |
| 07:40 | <mpt> | The first browser to choose to default to ignoring ping= would be (slightly) faster than those that observed it |
| 07:41 | <othermaciej> | what's the scarce resource with no allocation policy in this case? |
| 07:41 | <mpt> | So other browsers would eventually ignore it to match, driving site authors back to using server-side redirects. |
| 07:41 | <othermaciej> | what you describe is (perhaps) a race to the bottom, not a tragedy of the commons |
| 07:41 | <othermaciej> | however, I don't think ping would be a significant perf hit |
| 07:41 | <othermaciej> | as long as you prioritize it lower than actual I/O for the page you are loading |
| 07:42 | <mpt> | The scarce resource being bandwidth |
| 07:42 | <Hixie> | actually the great thing about ping="" is it can be implemented in a way that totally avoids any performance hit |
| 07:42 | <Hixie> | which is, as noted above, the second most important reason google is interested in it |
| 07:43 | <mpt> | Send the ping once everything else has finished transferring? |
| 07:43 | <Hixie> | othermaciej: and yeah, such a pref would be a quick way to kill the feature from our point of view :-) |
| 07:43 | <mpt> | ... in all browser windows? |
| 07:43 | <Hixie> | mpt: right |
| 07:43 | <mpt> | ... and other Internet-using software you happen to have open? |
| 07:43 | <Hixie> | mpt: four TCP packets aren't even going to be a blip on the radar if you wait for a lull |
| 07:43 | <mpt> | true |
| 07:44 | <othermaciej> | it's not the bandwidth that kills you in the redirect case, it's the latency |
| 07:44 | <Hixie> | and that's all you need (SYN, SYN/ACK, ACK, HTTP POST, close connection) |
| 07:44 | <Hixie> | yeah |
| 07:44 | othermaciej | loves saying "it's not the bandwidth, it's the latency" |
| 07:44 | <Hixie> | latency is all i care about these days |
| 07:44 | <Hixie> | bandwidth only matters when you're trying to watch video |
| 07:44 | <othermaciej> | it seems like the software engineer equivalent of "I'm a doctor, dammit, not an engineer" |
| 07:45 | <Hixie> | hah |
| 07:45 | <othermaciej> | bandwidth also matters when you are on EDGE and want to look at web sites |
| 07:45 | <Hixie> | i avoid such networks :-) |
| 07:46 | <Hixie> | i don't have any hardware even capable of connecting to such lame networks |
| 07:46 | <Hixie> | :-) |
| 07:46 | <othermaciej> | it certainly seems like such networks are on the way out |
| 07:46 | <othermaciej> | but latency is still a killer |
| 07:46 | <othermaciej> | this is why <script src=""> is worse than <img> for page loading performance |
| 07:47 | <othermaciej> | also why the http connection limit and the fact that pipelining is not practically usable taken together are bad |
| 07:47 | <othermaciej> | maybe sites should have some way to opt out of the connection limit |
| 07:50 | <Hixie> | <script async> baby |
| 07:51 | <Hixie> | the http limit is a pain, i agree |
| 07:51 | <Hixie> | not sure what to do about it |
| 07:51 | <Hixie> | there are sites that would quickly DOS themselves if it wasn't for that limit |
| 07:51 | <Hixie> | (e.g. flickr) |
| 07:54 | <othermaciej> | people ship Firefox extensions and Safari haxies to violate the connection limit for allegedly faster network perf |
| 07:54 | <othermaciej> | not sure if it works |
| 07:54 | <othermaciej> | another useful thing would be a reliable way for the site to report that it can support pipelining correctly |
| 07:54 | <othermaciej> | wait, that wouldn't work |
| 07:54 | <othermaciej> | I just remembered the reason we don't enable it is that apprently some proxies break in horrible ways |
| 07:55 | <othermaciej> | so an end-to-end header wouldn't help |
| 07:55 | <othermaciej> | can't remember if they are normal http proxies or transparent proxies |
| 07:55 | <othermaciej> | or indeed if they still exist |
| 07:55 | <othermaciej> | would flickr really blow up without the limit? (I have no idea) |
| 07:55 | <Hixie> | proxies are, from what i've heard in conversations with pretty much everyone who has ever deployed real end user software on the web, the worst pieces of software on the web |
| 07:56 | <othermaciej> | seems like with enough users, the connection limit won't actually reduce connections made per second |
| 07:56 | <Hixie> | i've heard horrible stories about proxies |
| 07:56 | <othermaciej> | assuming constant time to serve a request |
| 07:56 | <Hixie> | if you have N users, and you remove the connection limit on a page with 20 images, you'll got from 2N connections to 21N+ connections |
| 07:56 | <othermaciej> | no, I think I am doing bad math there |
| 07:57 | <Hixie> | s/got/go/ |
| 07:57 | <othermaciej> | I don't think max number of connections used would give the best perf, I doubt network stacks would schedule it that way |
| 07:58 | <othermaciej> | would probably just use more for data more likely to be latency-sensitive |
| 07:58 | <Hixie> | if you're selfish, and have ample bandwidth, why wouldn't opening as many connections as possible win? |
| 07:58 | <othermaciej> | and use some reasonable limit, like 4 or something, for images |
| 07:58 | <othermaciej> | pipelining would be better though |
| 07:58 | <Hixie> | what might help is to drop the connection limit for specific things, like <event-source> or TCPConnection (or whatever replaces them) |
| 07:59 | <othermaciej> | I guess it depends on how many it takes to saturate your bandwidth |
| 07:59 | <othermaciej> | once you've filled bandwidth adding more is bad |
| 07:59 | <Hixie> | sure |
| 07:59 | <Hixie> | and on dial-up that might be a concern |
| 07:59 | <Hixie> | and maybe even on low-end DSL or cable |
| 07:59 | <Hixie> | but there comes a point where you really aren't going to notice |
| 08:00 | <Hixie> | as far as i can tell |
| 08:00 | <Hixie> | anyway, i'm a doctor, not an engineer |
| 08:00 | <Hixie> | so... |
| 08:00 | <Hixie> | :-) |
| 08:00 | <Hixie> | i should sleep |
| 08:01 | <Hixie> | nn |
| 08:10 | <roc> | there's got to be a way to detect bad proxies |
| 08:10 | <roc> | like maybe we set up a special test site |
| 08:11 | <roc> | and when pipelining is enabled in the browser, every time the user's IP address changes, we send a test HTTP pipelining transaction to the test site |
| 08:43 | <othermaciej> | roc: proxy config can change w/o IP change |
| 08:43 | <othermaciej> | generally that is detectable |
| 08:43 | <othermaciej> | dunno about the transparent proxy case |
| 08:44 | <othermaciej> | the problem really is that in the failure case it's not always obvious at a machine level that the response is currupted |
| 08:51 | <roc> | yeah |
| 08:51 | <roc> | someone can always bring up a transparent proxy that causes pipelining requests to be mangled/hang |
| 08:52 | <roc> | but we have to figure out a way to unbreak this part of the Web |
| 08:52 | <roc> | one day... |
| 09:07 | <othermaciej> | it is a problem worth solving, but pretty tough |
| 09:07 | <othermaciej> | ironically something like Google Web Accelerator could solve it |
| 09:07 | <othermaciej> | though perhaps it also obviates the need for it |
| 09:08 | <Hixie> | 1 |
| 10:16 | <hsivonen> | where do I find the allowed whitespace positions in mime types? |
| 10:17 | <hsivonen> | surely text / plain is not allowed? |
| 10:18 | <zcorpan> | i remember this being discussed here (or in #html-wg) a few weeks ago |
| 10:19 | <hsivonen> | I figured that parsing media queries manually was a mistake, so I'm going with ANTLR for mime types |
| 10:20 | <hsivonen> | I haven't figured out yet how to get human-friendly error messages out of ANTLR, though |
| 10:21 | <kfish> | hsivonen, do you mean the allowed whitespace in something like "text/plain; charset=us-ascii (Plain text)" ? |
| 10:22 | <hsivonen> | kfish: yes. where is it defined that WS around the semicolon is OK but around the slash (presumably) not? |
| 10:22 | <kfish> | http://www.ietf.org/rfc/rfc2045.txt |
| 10:22 | <hsivonen> | hmm. I didn't find it there |
| 10:22 | <kfish> | section 5.1 has the bnf |
| 10:23 | <kfish> | content := "Content-Type" ":" type "/" subtype |
| 10:23 | <kfish> | where type and subtype are basically made of token |
| 10:23 | <kfish> | token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, |
| 10:23 | <kfish> | or tspecials> |
| 10:24 | <hsivonen> | so where does it say that space after the semicolon is OK? |
| 10:24 | <hsivonen> | are where does it say that inter-token WS is always OK? |
| 10:24 | <hsivonen> | s/are/or/ |
| 10:28 | <Philip`> | http://www.ietf.org/rfc/rfc2616.txt - "implied *LWS" "Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field." |
| 10:32 | <hsivonen> | Philip`: that would allow white space like this "text / html" |
| 10:32 | <hsivonen> | Philip`: is that actually supported? |
| 10:32 | <kfish> | and rfc822 explicitly allowed spaces around the @ in email addresses |
| 10:32 | <hsivonen> | kfish: scary |
| 10:33 | <kfish> | seems to have been cleaned up in 2822 |
| 10:33 | <kfish> | (and newlines, i might add ...) |
| 10:33 | <Philip`> | data:text / html,<b>Test suggests maybe in Firefox |
| 10:39 | <hsivonen> | In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. |
| 10:39 | <hsivonen> | argh. who came up with the idea of allowing comments in headers? |
| 10:41 | <Philip`> | http://philip.html5.org/demos/http/content-type/text-html vs http://philip.html5.org/demos/http/content-type/text-plain suggests IE/Firefox/Opera don't accept "text / html" |
| 10:42 | <hsivonen> | yay |
| 10:42 | <hsivonen> | time to send email I guess |
| 10:42 | <Philip`> | (Not sure why data:text / html,... works in Firefox) |
| 11:07 | <hsivonen> | were these RFCs written before there was a requirement for "rough consensus and *running code*" at the IETF? |
| 11:07 | <hsivonen> | I mean: one would think that actual implementors would have revolted over some of the gratuitous complexity |
| 11:51 | <hsivonen> | hmm. with RFC 2616 media type simplification rules, ANTLR looks like an overkill again... |
| 12:00 | hsivonen | is unhappy due to time wasted over RFC 2045 considering that RFC 2616 is much better on the media type point |
| 12:01 | <annevk> | you could just ignore it |
| 12:01 | <annevk> | it's not even a comment on the intro doc |
| 12:10 | <hsivonen> | annevk: I didn't mean Julian's comments. I meant my efforts to implement conformance checking for attributes that take a MIME type optionally with parameters |
| 12:12 | <hsivonen> | I'm rather unhappy that I followed the normative reference to the MIME RFC rathole instead of realizing right away that I should have known to read RFC 2616 instead |
| 12:51 | <annevk> | hsivonen, ah, I see |
| 12:51 | <annevk> | somehow we need to solve the HTTP mess... |
| 12:51 | <annevk> | but I guess that's simply said... |
| 16:10 | <gsnedders> | Philip`, hsivonen: Implied LWS is explicitly disallowed around the slash in MIME types |
| 16:11 | <Philip`> | gsnedders: I think the problem was it isn't explicit in RFC2045 |
| 16:11 | <gsnedders> | ah |
| 16:48 | <Hixie> | hsivonen: sorry about out of date references -- they're the best references i am aware of when i make the reference, but i have trouble keeping track of what's what, that's why i haven't updated them and why the section doesn't yet exist |
| 16:48 | <Hixie> | if i don't have a references section, people can't claim they're out of date |
| 16:48 | <Hixie> | at least that was the theory |
| 16:49 | <Hixie> | in practice people complain about as much, i just ignore them more :-) |
| 17:36 | <gsnedders> | Lachy: yes |
| 17:42 | <Lachy_> | gsnedders, ? |
| 18:58 | <gsnedders> | Lachy: accessing your site |
| 20:13 | hsivonen | wonders if HTTP implementations really support backslash escaping control chararacters... |
| 21:23 | <gsnedders> | hsivonen: Mozilla in places just keeps the slashes and everything until double quote not preceeded by a slash |
| 21:25 | <hsivonen> | gsnedders: is there a bug filed? what do other browsers do? |
| 21:25 | <gsnedders> | hsivonen: dunno. |
| 21:25 | <gsnedders> | hsivonen: I've had so little time to reverse engineer such things |
| 21:26 | <gsnedders> | hsivonen: Mozilla doesn't have a unified place for decoding quoted-string, and does it all over the place |
| 22:52 | <Hixie> | i wish i understood what karl was trying to say in his last e-mail |
| 23:03 | <Lachy_> | Hixie, I think he's trying to say that determining the demand for a feature is subjective and depends upon who is asked |
| 23:05 | <jgraham_> | I can't say it makes a lot of sense to me, but Lachy_'s interpretation seems plausible |
| 23:10 | <gavin> | I interpreted it as "there are features currently in the spec for which I haven't seen requests on the mailing lists" |
| 23:11 | <Lachy_> | that would be because most of the features in the spec were discussed on the whatwg list well before the htmlwg started |
| 23:11 | <Lachy_> | and also because demand for a feature can come from a lot more places than just the mailing list |
| 23:13 | <gavin> | yeah, I know |
| 23:13 | <gavin> | but his message gave me the impresion that he doesn't see it that way |
| 23:15 | <Hixie> | well, the former interpretation is a truism, so i doubt that's what he meant |
| 23:15 | <Hixie> | gavin's interpretation makes sense, but i'm not sure what karl expects me to do with it if that's what he meant |
| 23:16 | <Hixie> | since it's clear that public-html is far from the only source that we should look at |
| 23:16 | <jgraham> | I think the implication is that the spec has solicited input from a subset of its potential users and so is biased toward the desires of those people |
| 23:17 | <webben_> | Hixie: Can't you just ask? (what Karl meant) |
| 23:18 | <Hixie> | i haven't had good luck asking karl what he meant in the past |
| 23:18 | <webben_> | ah |
| 23:22 | <jgraham> | (in addition it seems to imply that the development has been on a "we go to some community and ask what they want out of html" model, which I don't think matches reality) |
| 23:24 | <Hixie> | jgraham: the implication that the spec has solicited input only from a subset of its potential users (and so is biased) is true, of course |
| 23:24 | <Hixie> | not sure how to avoid that |
| 23:25 | <Hixie> | anyway |
| 23:25 | <Hixie> | it would de helpful if karl made it clearer in his e-mails what he desired from his e-mails |
| 23:26 | <webben_> | Hixie: Regardless of what Karl meant, I suppose the way to solicit input from lots of users is to simply ask different communities for input. I suspect the challenge would be translating such input into stuff that's in scope for HTML. But that doesn't mean it would be a worthless procedure. |
| 23:26 | <jgraham> | Hixie: Of course not all communities are equally easy to reach but the doors for feedback have always been open |
| 23:27 | <jgraham> | so in principle, any community can provide input |
| 23:27 | <Hixie> | webben_: right, that's what we've been doing for years |
| 23:28 | <webben_> | Hixie: Haven't most of these users been technical? |
| 23:28 | <Hixie> | many have, but by no means all |
| 23:28 | <Hixie> | most of html's target audience is technical, though, so that bias is to be expected |
| 23:29 | <webben_> | No. Most of HTML's target audience is technically illiterate. It's just that their use of HTML is mediated through applications. |
| 23:29 | <Hixie> | i should rephrase |
| 23:29 | <webben_> | actually if you include stuff like blog comments, maybe even most HTML authors are technically illiterate |
| 23:29 | <Hixie> | most of web apps 1.0's target audience was technical |
| 23:29 | <webben_> | ah yes |
| 23:29 | <Hixie> | html5's primary goal is extending html to apply to web application authors |
| 23:29 | <Hixie> | who are technical |
| 23:30 | <jgraham> | There is a distinction to be made between HTML+DOM and content-that-happens-to-be-in-HTML |
| 23:31 | <jgraham> | HTML+DOM is mainly aimed at technical users (although hopefully with a very low barrier to entry) |
| 23:31 | <jgraham> | HTML content is aimed at everyone |
| 23:31 | <webben_> | jgraham: where do comments on blogger fit into that scheme |
| 23:32 | <webben_> | (Blogger allows markup like b and i) |
| 23:33 | <jgraham> | webben_: Essentially HTML is an implementation detail there; they could be using a GUI editor or markdown or anything else. But it happens that a subset of HTML-the-language is easy enough for many non-technical people to use |
| 23:33 | <jgraham> | Which is a good thing and I think we should consider those uses |
| 23:33 | <othermaciej> | I'm not sure if non-technical users could express their needs in a very useful form |
| 23:33 | <jgraham> | by e.g. keeping <b> and <i> |
| 23:34 | <othermaciej> | you'd have to use techniques like user testing to get useful data |
| 23:34 | <othermaciej> | or otherwise make indirect inferences from behavior patterns |
| 23:34 | <webben_> | othermaciej: That's possibly true. Maybe that's an essential part of soliciting input. |
| 23:34 | <Hixie> | (note that i have used input from usability studies on users of wysiwyg editors in drafting html5) |
| 23:35 | <webben_> | Hixie: That's good. |
| 23:42 | <webben_> | Does HTML5 have a document listing persona yet? |
| 23:46 | <Hixie> | persona? |
| 23:47 | <webben_> | http://en.wikipedia.org/wiki/Personas |
| 23:48 | <webben_> | it was an idea raised early on in public-html somewhere ... at some point someone linked to the WAI personas |
| 23:48 | <webben_> | but that's only one aspect of HTML usership |
| 23:48 | <Hixie> | i do not believe anyone has written a document describing use cases from the point of view of fictious characters, no |
| 23:50 | <jgraham> | I always wonder about the value of such documents; it's hard to say if a fictional use case scenario corresponds to reality or not |
| 23:51 | <Hixie> | if anyone wants to write such a document, i'm certainly not opposed. the whatwg wiki is available as a place to put such discussions, if needed. |
| 23:51 | <webben_> | jgraham: That's true. But it's equally hard to say if a use case scenario considered in the abstract corresponds to reality or not. |
| 23:51 | <Hixie> | we don't tend to consider use cases in the abstract |
| 23:51 | <othermaciej> | I'm not sure personas are a useful abstraction for extremely widely deployed technical specifications |
| 23:51 | <Hixie> | for most features the use cases are derived straight from actual feedback |
| 23:52 | <othermaciej> | they are most useful for end-user applications with a specialized but not monolithic target audience |
| 23:52 | <Hixie> | e.g. the offline stuff is derived straight from experience the Google Reader team had in developing an offline version of Google Reader |
| 23:52 | <Hixie> | (amongst other things) |
| 23:52 | <Hixie> | similarly, i took experience from the YouTube, Google Video, and (in the form of feedback and discussions) the Quicktime teams in writing the video section |
| 23:53 | <Hixie> | all of which is very much not abstract :-) |
| 23:54 | <webben_> | Does the HTML5 WG have a way by which your average Joe can send feedback? |
| 23:54 | <Hixie> | the html5 wg, or the whatwg? |
| 23:54 | <Hixie> | the whatwg has several |
| 23:54 | <webben_> | Or would they need to send it to WHATWG? |
| 23:54 | <webben_> | I'm talking about the HTML5 WG. |
| 23:55 | <Hixie> | i don't know that the w3c is really set up for getting feedback from random joe |
| 23:55 | <Hixie> | i suppose they could mail www-html⊙wo, i follow that |
| 23:55 | <Philip`> | public-html-comments⊙wo? |
| 23:55 | <Hixie> | oh, is that active? |
| 23:55 | <webben_> | Maybe the HTML WG homepage should say? |
| 23:55 | <Hixie> | maybe. tell the people in #htmlwg :-) |
| 23:55 | <Philip`> | It had two emails this month, so presumably it works |
| 23:55 | <Hixie> | (i don't have access to those pages, i don't think) |
| 23:55 | <Hixie> | Philip`: ah |
| 23:56 | <Hixie> | i'd better make sure i'm subscribed |
| 23:57 | <Philip`> | Hmm, 14% of the list's posts is spam |
| 23:57 | <webben_> | I assume that's true of any W3C list that isn't looked after. |
| 23:57 | <Philip`> | or maybe it's 17% |
| 23:58 | <Philip`> | http://lists.w3.org/Archives/Public/public-html-comments/ says September had 3 posts, but http://lists.w3.org/Archives/Public/public-html-comments/2007Sep/ shows two |
| 23:58 | Hixie | wonders what a good way of faking |span { content: '' }| would be |
| 23:58 | <Hixie> | i suppose i have to use the evil text-indent trick |