| 00:00 | <Hixie> | so some of this feedback about responsive images suggests we should send differnet images based on bandwidth |
| 00:00 | <Hixie> | any ideas how to do that? |
| 00:00 | <Hixie> | (i mean at a high level, not syntax levle) |
| 00:01 | <Hixie> | should we just have two categories, "i am bandiwdth-constrained" and "i am willing to try for the biggest thing you have"? |
| 00:02 | <mpt> | "This is taking too long, please give me the rest of the image at the next lowest resolution" |
| 00:04 | <Hixie> | yeah but what if the user then comes out of the tunnel? |
| 00:05 | <Hixie> | what if it took a long time because the user started on wifi but the wifi router got hit by a dog? |
| 00:07 | <jsbell> | FWIW, at <previous company> with a non-Web client we used JPEG2000 progressive images. The client would just terminate the request when it had enough pixels to display, but could always do an HTTP Range request for more later on, if e.g. the user zoomed in. |
| 00:10 | <jsbell> | (More specifically, the client would request only the first 1k of data, and reason about how much more to request based on current conditions. This require the rendering pipeline and image cache to be fairly chatty.) |
| 00:20 | <tantek> | Hixie, my understanding is that the folks who've been exploring responsive images have thought through a lot of the use cases etc. You'll likely answer your questions better with some web research (unless folks here have specific URLs to such research)) |
| 00:20 | <tantek> | and yes, I agree, figure out the high-level mechanics of it first, worry about syntax later. |
| 00:21 | <Hixie> | some of the folks who've been exploring responsive images have sent zillions of e-mails on the topic to the whatwg list |
| 00:21 | <Hixie> | so i'm pretty well covered in terms of research |
| 00:21 | <tantek> | email != research in my experience. that's part of the problem. |
| 00:22 | <Hixie> | i mean, they did research, and e-mailed it to the list |
| 00:22 | <tantek> | have any sent URLs to wiki pages of research? |
| 00:22 | <Hixie> | (which is the best way to do things in the whatwg world) |
| 00:26 | <tantek> | Hixie, it works best for you, because you've chosen to treat the whatwg list as your inbox / task list. In every other way, I've found email lists (including WHATWG) to be more of a support forum, and rarely useful for much else. Though to be fair WHATWG has a decent S/N. |
| 00:27 | <Hixie> | well the help⊙wo list is a support forum by design, sure |
| 00:27 | <Hixie> | the whatwg⊙wo list is a spec feedback list by design |
| 00:27 | <Hixie> | having promised to reply to all e-mail goes a long way towards enforcing that, i think :-) |
| 00:28 | <Hixie> | (still reading it all, but so far the focus has been on image dimensions and pixel density, i haven't seen much about the network bandwidth side of responsive design, either on the threads or on the web.) |
| 00:32 | <tantek> | that being said, good to hear that you're working on responsive images - I think it will be a significant improvement to the adaptability of the web platform. |
| 00:33 | <tantek> | (and it's content and belongs in markup, rather than presentational CSS) |
| 00:35 | <Hixie> | well it belongs in both |
| 00:35 | <Hixie> | depends on what kind of image we're talking about :-) |
| 01:41 | <abarth> | Hixie, I didn't read the whole discussion above, but I don't know of anyone who is using "always" |
| 01:41 | <abarth> | Hixie: the "origin" mode seems to be the most popular |
| 03:28 | <Hixie> | lol |
| 03:29 | <Hixie> | so i've now sent enough e-mails to w3cmemes' e-mail address that google+ recommended it as a friend |
| 03:29 | <Hixie> | so i tried to add it as a friend |
| 03:30 | <Hixie> | and that sent an e-mail to w3cmemes' e-mail address asking it to join google+ |
| 03:30 | <Hixie> | which has now appeared on the tumblr -_- |
| 03:53 | <tantek> | Hixie - LOL |
| 04:00 | <kennyluck> | LOL |
| 05:17 | <AryehGregor> | jgraham, thanks. |
| 07:07 | <zcorpan> | defaults write -g ApplePressAndHoldEnabled -bool false <-- aaaaaaaah, that feels so much better |
| 07:16 | <jgraham> | AryehGregor: Not committed yet; if you have time to do a quick code review on the gist I would be happy |
| 07:22 | <hober> | zcorpan: yeah, I have (ns-set-resource nil "ApplePressAndHoldEnabled" "NO") in ~/.emacs |
| 08:04 | <hsivonen> | rafaelw_: Sorry about the delay in reply. I changed my filters to put public-webapps under my WHATWG label instead of my catchall W3C label from now on so that they don't get lost among the volume of the long tail of W3C lists I subscribe to |
| 08:06 | <hober> | Hixie: heh. deleted. |
| 08:08 | <jgraham> | hsivonen: I don't really like the idea of shoving four methodsWithLongNames on document |
| 08:11 | <jgraham> | If we believe that people prefer jQuery-style APIs to legacy-DOM-style APIs then that clearly isn't going to be popular |
| 08:11 | <jgraham> | So it will probably be wrapped in a way that reintroduces per-library magic and regexps |
| 08:16 | <hsivonen> | jgraham: Please suggest shorter names on the list. I think it makes more sense to call a single method than to first call a factory method and then set a property on the object returned by the factory method. |
| 08:21 | <jgraham> | Well the best API I can come up with is document.parse(string, ["auto"|"html"|"svg"|"mathml"|"xml"]) |
| 08:22 | <jgraham> | Where auto does some sort of magic, and the other options allow you to opt-out of the magic |
| 08:25 | <zcorpan> | tabatkins: would it be ok to have <template context=svg>? |
| 08:26 | <zcorpan> | why do we need "xml"? what would it do? |
| 08:28 | <zcorpan> | do we want contextless xml fragment parsing? |
| 08:36 | <tabatkins> | zcorpan: Maybe? It's not *horrible*, but I'd prefer to avoid it if possible. |
| 08:36 | <tabatkins> | Maybe if it was an optional switch, so we could use it to switch on <template><a>...</></> stuff. |
| 08:37 | <tabatkins> | But still by default use the "first start tag" thing. |
| 08:38 | <tabatkins> | Then we can just say "conflicts resolve in favor of HTML" without guilt. |
| 08:51 | <AryehGregor> | jgraham, I'm not sure about it until Ms2ger gets back to us on why he wants explicit timeouts instead of no test-wide timeouts at all. |
| 08:53 | <AryehGregor> | window.getLastError? Seriously? Unix's errno was so amazingly successful and non-error-prone that people need to reinvent it in JS? |
| 08:54 | <AryehGregor> | Oh, it only needs to work from window.onerror handlers. That would make some sense, although the API could be improved upon. |
| 08:55 | <jgraham> | And Ms2ger has just quite. OF course. |
| 08:55 | <jgraham> | *quit |
| 08:57 | <jgraham> | If you wanted to do that getLAstError thing, why wouldn't you just make it a property of the event? |
| 09:01 | <AryehGregor> | What event? This is window.onerror. |
| 09:01 | <AryehGregor> | It's not an actual event handler. :) |
| 09:08 | <jgraham> | Oh. Well something that passes the error object to the "event" handler then |
| 09:09 | <jgraham> | Not some global function that doesn't work in some situations |
| 09:12 | <AryehGregor> | What do you mean? |
| 09:12 | <AryehGregor> | window.onerror is the only thing that gets called for uncaught JS exceptions, right? |
| 09:12 | <zcorpan> | AryehGregor: it is a an actual event handler, but there's no actual event :-) |
| 09:14 | <jgraham> | AryehGregor: I mean if you have some function f that is called in response to an exception e, e is an argument of, or a property of an argument of, f |
| 09:14 | <AryehGregor> | jgraham, that would be nice, but it's not true for window.onerror, is it? |
| 09:15 | <zcorpan> | what you're suggesting is proposal #2 |
| 09:18 | <jgraham> | zcorpan: So it is |
| 09:18 | <jgraham> | No idea why the author thinks it's less preferable |
| 09:18 | <jgraham> | It seems obviously better to me |
| 09:19 | <jgraham> | Although if IE uses e = this, that seems like an interesting alternative |
| 09:22 | <zcorpan> | this is window in IE9 |
| 09:22 | <odinho> | I also liked the #2 better. |
| 09:23 | <jgraham> | zcorpan: Oh well in that case I guess #2 is best |
| 09:24 | <zcorpan> | WDYT about #3 (just the stack in an argument)? |
| 09:26 | <jgraham> | Seems more logical to make TC39 add the stack as a property of the event |
| 09:27 | <jgraham> | of course they will probably reject that idea |
| 09:27 | <jgraham> | Because they don't like the idea of functions being able to know their callstack |
| 09:28 | <jgraham> | s/event/Error/ |
| 09:37 | <odinho> | If everyone is doing it anyway, well, they don't have much to say then I guess :P |
| 09:43 | <annevk> | hober: you should delete the tweet too |
| 09:43 | <hober> | annevk: ok |
| 09:44 | <annevk> | hober: also, welcome to Europe, discussing prefixes? :) |
| 09:45 | <hober> | not yet, thank $deity |
| 09:45 | <hober> | right now we're talking about compositing & blending |
| 09:45 | <jgraham> | Pretty sure that prefixes are evidence that $deity is null |
| 09:45 | <annevk> | jgraham: only if you assume he's good |
| 09:46 | <hober> | jgraham: or that $deity is (not null) && vengeful |
| 09:46 | <annevk> | minutes in memespeak http://w3cmemes.tumblr.com/post/22708671971 |
| 09:46 | annevk | approves |
| 09:58 | <hober> | more minuting... http://w3cmemes.tumblr.com/post/22709255224 |
| 09:59 | <gsnedders> | odinho: Eh, there's plenty of stuff everyone supports but is unspec'd. |
| 10:00 | <gsnedders> | jgraham: wrt stack/stacktrace, I think it was decided to wait to see what impls decide to do for PTC, given TCO is required. |
| 10:01 | <jgraham> | gsnedders: You appear to have started speaking in tounges |
| 10:03 | <jgraham> | Or to put it more pleasantly, you have given in to glossolalia |
| 10:05 | <gsnedders> | s/PTC/proper tail calls/ |
| 10:05 | <gsnedders> | s/TCO/tail call optimization/ |
| 10:06 | <jgraham> | Required by what? |
| 10:06 | gsnedders | has obviously spent too much time dealing with compilers |
| 10:06 | <jgraham> | Not that I am against TCO |
| 10:06 | <gsnedders> | jgraham: The spec, as it's trivially black-box observable (running out of stack) |
| 10:07 | <jgraham> | Well I guess I should have got TCO, which might have given a clue for PTC |
| 10:07 | <jgraham> | Required by which spec? |
| 10:07 | <gsnedders> | ES6 |
| 10:08 | <jgraham> | So the tl;dr summary is "ES6 will introduce tail call optimisation (which may screw with stack traces)" |
| 10:09 | <gsnedders> | Yeah. |
| 10:10 | <gsnedders> | A large part of why Java has never had TCO is the fact the spec requires stacktraces for errors, which effectively mean having a stack. |
| 10:10 | <gsnedders> | *means |
| 10:11 | <jgraham> | Guido has the same reasoning for python (debuggability > recursion) |
| 10:12 | <jgraham> | But doesn't relying on TCO mean that your stack must have the form (roughly) A B C [D E F]* |
| 10:12 | <jgraham> | Or |
| 10:15 | <gsnedders> | jgraham: Any function with a PTC will not be on the stack after the tail call. |
| 10:15 | <gsnedders> | Or what? |
| 10:15 | <jgraham> | gsnedders: It won't be on the stack, obviously |
| 10:15 | gsnedders | needs to pack for Lkpg though |
| 10:16 | <jgraham> | I was just wondering if the stack that you would get in the absence of tail calls has to be regular in a way that would allow you to display something quite useful as a traceback |
| 10:16 | <jgraham> | even when you do have tco |
| 10:16 | <jgraham> | But I'm not sure that I'm right |
| 10:17 | <jgraham> | gsnedders: When do you arrive? |
| 10:17 | <gsnedders> | Well, you have no idea where the function was directly called from |
| 10:17 | <gsnedders> | jgraham: Late. Really late. |
| 10:17 | <jgraham> | OK |
| 10:17 | <jgraham> | To where? |
| 10:17 | <gsnedders> | Du Nord |
| 10:17 | <jgraham> | That's in Paris? |
| 10:17 | <gsnedders> | Flying into NYO |
| 10:17 | <jgraham> | Ah OK |
| 10:18 | <gsnedders> | From EDI |
| 10:18 | <jgraham> | That was the question |
| 10:18 | <gsnedders> | Ah. |
| 10:18 | <jgraham> | You have checked that there is actually a bus, right? |
| 10:18 | <gsnedders> | Yes. |
| 10:18 | <gsnedders> | Gets in at 23:15, IIRC |
| 10:18 | <gsnedders> | (the bus) |
| 10:18 | <jgraham> | OK |
| 10:19 | <gsnedders> | Staying at Hotell Du Nord, on Repslagaregatan (sp?) |
| 10:20 | <zcorpan> | ok so looking at http://kangax.github.com/es5-compat-table/non-standard/ and removing all columns except opera, ie9, ff12, sf5 and ch7-10, and removing lines where there are more "No" than "Yes", gives: |
| 10:20 | <zcorpan> | function statement , function "name" property, function "caller" property, function "arguments" property, __proto__ , __defineGetter__ , __defineSetter__ , const, RegExp "lastMatch", RegExp.$1-$9, String.prototype.substr, String.prototype.trimLeft, String.prototype.trimRight, String.prototype.anchor, String.prototype.big, String.prototype.blink, String.prototype.bold, String.prototype.link, Octal literals, error "stack" |
| 10:21 | <gsnedders> | Quite a few of those are in ES6 |
| 10:21 | <zcorpan> | what's missing? |
| 10:22 | <gsnedders> | Off hand, function properties, __define{G,S}etter__ (note IE doesn't support this), Error.stack |
| 10:22 | <gsnedders> | IE doesn't support Error.stack either |
| 10:23 | <zcorpan> | what about function statement? (http://kangax.github.com/nfe/#function-statements ) |
| 10:23 | <gsnedders> | Believe they're in, though no idea what the semantics are |
| 10:25 | <zcorpan> | where's the es6 spec? |
| 10:26 | <gsnedders> | Not everything that's been agreed to be added is in the spec yet, but http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts |
| 10:26 | <gsnedders> | Also still not agreement on __proto__ semantics |
| 10:27 | <gsnedders> | Noteably what us and JSC have impls of now are slightly different to what's in the spec, and in IMHO cleaner |
| 10:28 | <zcorpan> | i don't see anchor() anywhere |
| 10:29 | <gsnedders> | "Not everything that's been agreed to be added is in the spec yet" |
| 10:29 | <zcorpan> | k |
| 10:34 | <gsnedders> | jgraham: What's the weather like? :P |
| 10:34 | <jgraham> | Today? Lousy |
| 10:34 | <jgraham> | Rain |
| 10:35 | <gsnedders> | How warm? |
| 10:35 | <jgraham> | I haven't worked out how to get the temperature to display in unity yet |
| 10:35 | <jgraham> | http://www.temperatur.nu/ullstamma.html |
| 10:35 | <gsnedders> | Should I plan to wear enough not to be frozen given snow everywhere, or enough to not be frozen given a sane spring temperature? |
| 10:36 | <gsnedders> | Okay. |
| 10:37 | <jgraham> | In other UI rants, who thought that hiding the menu headings in unity was a good idea? It reduces discoverability and increases aquisition time |
| 10:38 | jgraham | decides to blame mpt |
| 10:38 | <jgraham> | I can only imagine it is part of some long-term plan to make application designers stop using menus |
| 11:03 | <jgraham> | Is there some way to tell from script if a CSS background image has finished loading? |
| 11:03 | <annevk> | load it through new Image and time that? |
| 11:05 | <jgraham> | Well for my purposes I could rely on timing |
| 11:05 | <jgraham> | But I would rather not |
| 11:05 | <jgraham> | (makes tests more unstable) |
| 11:06 | <annevk> | unless something changed in the last couple of months CSSOM does not expose much in this area |
| 11:06 | <jgraham> | Yeah and we still don't have drawElement in the 2D context |
| 11:06 | <jgraham> | Timing it is, I guess |
| 11:11 | <jgraham> | Next question: is it me, or is http://www.whatwg.org/specs/web-apps/current-work/#critical-subresources a lie? |
| 11:12 | <jgraham> | In particular, it seems that background images in CSS do delay the load event |
| 11:12 | jgraham | hasn't tried anything else yet |
| 11:33 | <annevk> | jgraham: even background images that don't apply at the moment? |
| 11:33 | <annevk> | jgraham: e.g. @media (min-width:10000px) { body { background:url(trololol.jpg) } } |
| 11:34 | <annevk> | jgraham: because if browser load those they're being silly |
| 11:34 | <annevk> | browsers* |
| 11:43 | <zcorpan> | jgraham: yeah they delay the load event (if they're loaded). but no spec mentions that, iirc |
| 11:43 | <zcorpan> | same with web fonts |
| 11:48 | <jgraham> | The HTML spec specifically says that they don't |
| 11:48 | <jgraham> | Fun fun |
| 11:49 | <annevk> | again, not all of them do |
| 11:49 | <jgraham> | annevk: example? |
| 11:49 | <annevk> | jgraham: see above? |
| 11:50 | <jgraham> | annevk: I haven't tried media queries, but display:none doesn't seem to stop the delay |
| 11:50 | <annevk> | selectors that don't apply? |
| 11:51 | <jgraham> | Haven't tried that |
| 11:52 | <jgraham> | But how do you tell that they don't apply? |
| 11:53 | <annevk> | #test { ... } |
| 11:53 | <annevk> | there was this site once that had about a 100 different background images depending on weather conditions and time of day |
| 11:53 | <jgraham> | Hmm, that doesn't seem to block the load event |
| 11:53 | <annevk> | all linked from the stylesheet and the markup would change |
| 11:54 | <annevk> | some browsers did load them all, they quickly changed that |
| 11:54 | <jgraham> | Doesn't that just give lag when things change? |
| 11:54 | <annevk> | prolly |
| 11:54 | <annevk> | but downloading a 100 images and keeping them around when only one is shown is kind of wasteful |
| 11:55 | <jgraham> | So basically onload is tightly coupled to layout in a way that is totally undefined? |
| 11:55 | <annevk> | well layout is not defined |
| 11:55 | <annevk> | so yes, that would follow from that |
| 11:58 | <annevk> | heycam: any news yet on when you're going to reply to my email? |
| 12:00 | <heycam> | annevk: ah which email is it again? I'll try to reply now :) |
| 12:00 | <heycam> | (otherwise I'm off on leave for a week) |
| 12:02 | <annevk> | heycam: http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0137.html yay |
| 12:02 | <annevk> | heycam: vacation time? |
| 12:02 | <heycam> | annevk: once I hop on this plane and arrive back home, yeah |
| 12:08 | <heycam> | annevk: replied, not sure if you're looking for a deeper answer |
| 12:09 | <heycam> | annevk: mm this airport wifi might be blocking my smtp connection |
| 12:09 | <annevk> | is the answer "seemed to made sense"? |
| 12:09 | <heycam> | pretty much. for things like say insertBefore(node, undefined), that needs to be have like insertBefore(node, null) |
| 12:10 | <heycam> | I think it was just an oversight that I fixed |
| 12:10 | <annevk> | why does that need to behave the same? |
| 12:10 | <heycam> | because that's how implementations behave |
| 12:10 | <annevk> | I'm asking as someone internally wanted to make it throw |
| 12:10 | <heycam> | the alternative is to throw an exception |
| 12:10 | <annevk> | right okay |
| 12:11 | <heycam> | I see |
| 12:11 | <heycam> | well, passing undefined to something that would normally expect null seems fine |
| 12:11 | <annevk> | anyway, this makes sense to me, I'll ask him if he wants to pursue this further |
| 12:11 | <heycam> | if you were writing something in JS you'd be more likely to do a test like if (child) |
| 12:11 | <heycam> | ok cool |
| 12:11 | <heycam> | sorry for the delay |
| 12:13 | <heycam> | (the mail will probably arrive once I'm back home with decent network) |
| 12:15 | <annevk> | k |
| 12:21 | <annevk> | i love this one http://w3cmemes.tumblr.com/post/22670112919 |
| 12:21 | <annevk> | i wonder where that face is from |
| 12:24 | <michel_v> | a spanish politician, IIRC |
| 14:31 | <jzaefferer> | I'm working on a custom tooltip implementation for jQuery UI, and were running into problems related to ARIA and removing the native tooltip. We set the title to an empty string to disable the native tooltip, but that causes problems with screenreaders. I've found this Chromium ticket, suggesting that event.preventDefault on mouseover should prevent the native tooltip: http://code.google.com/p/chromium/issues/detail?id=42549 There's no mention of th |
| 14:34 | <jzaefferer> | (apparently my message was too long? here's the last part again) |
| 14:34 | <jzaefferer> | There's no mention of that in the spec: http://dev.w3.org/html5/spec/global-attributes.html#the-title-attribute - is that something that could or should be added? |
| 15:26 | <mpt> | jgraham, Mark Shuttleworth |
| 15:27 | <mpt> | jgraham, Ubuntu 12.10 will have an option to show menu titles all the time -- though why anyone would want that option turned off, I don't know |
| 15:27 | <jgraham> | mpt: He decided that UI personally? Interesting… |
| 15:28 | <jgraham> | Great, that sounds like something to look forward to |
| 16:18 | <dglazkov> | good morning, Whatwg! |
| 16:27 | <smaug____> | good evening |
| 17:10 | <zcorpan> | Hixie: could you have a look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 ? it should be blocking the <template> problem everyone's trying to solve |
| 18:45 | <jgraham> | Can't we make whatwg.org/html the default version of the spec yet? |
| 18:45 | <jgraham> | Uh |
| 18:45 | <jgraham> | s/default/single page/ |
| 18:59 | <annevk> | jgraham: use whatwg.org/c |
| 19:02 | <kennyluck> | Are there now more people in favor of the single page version? |
| 19:11 | <Ms2ger> | jgraham, please, no :) |
| 19:12 | annevk | always uses whatwg.org/C for multi-page |
| 19:24 | <jgraham> | PF |
| 19:25 | <annevk> | jgraham: hmm? |
| 19:25 | <jgraham> | Uh, network problems |
| 19:26 | <jgraham> | Ms2ger: Browsers cope with it a lot better than a few years ago |
| 19:26 | <jgraham> | and it is way more useful |
| 19:28 | <Ms2ger> | So, what did you want to ask me ten hours ago? |
| 19:29 | <Ms2ger> | (re timeouts / testharness.js) |
| 19:30 | <jgraham> | Ms2ger: https://gist.github.com/2636212 |
| 19:30 | <jgraham> | Is my proposal-as-code |
| 19:31 | <Ms2ger> | What's load_test_attr on line 12? |
| 19:31 | <jgraham> | gsnedders: You are at zcorpan's desk btw |
| 19:32 | <jgraham> | Ms2ger: Oh, copy and paste detris |
| 19:34 | <Ms2ger> | Do you want to do the clearTimeout in Tests.prototype.set_timeout? I guess you do |
| 19:34 | <jgraham> | Yeah, |
| 19:35 | <Ms2ger> | Velmont, exception ping ;) |
| 19:36 | <Ms2ger> | jgraham, is setup({ timeout: foo, explicit_timeout: true }) silly, and should it throw? |
| 19:38 | <jgraham> | Ms2ger: Yeah, it probably could |
| 20:20 | <jsocol> | hey Hixie et al |
| 20:20 | <jsocol> | so I have an example here: https://gist.github.com/2648133 and I've been reading through the parsing spec |
| 20:21 | <Ms2ger> | Hi again! |
| 20:21 | <jsocol> | and it seems like going from "end tag open state" to "tag name state" is a mistake |
| 20:21 | <Ms2ger> | Intentional, I'm pretty sure |
| 20:21 | <jsocol> | because "tag name state" can go to "before attribute name state" or "self-closing start tag state" |
| 20:22 | <jsocol> | and the definition of an end tag doesn't allow either of those states |
| 20:22 | <Ms2ger> | What do you mean by "allow"? |
| 20:22 | <jsocol> | so it seems like there should be an "end tag name state" that is basically the same as "tag name state" but never goes to "before attribute name state" or "self-closing start tag state" |
| 20:22 | <jgraham> | You can have end tags in attributes in the parser |
| 20:22 | <jsocol> | Ms2ger: http://dev.w3.org/html5/spec/syntax.html#end-tags |
| 20:22 | <Ms2ger> | That's you mistake |
| 20:22 | <Ms2ger> | your* |
| 20:22 | <jsocol> | there can be trailing whitespace after the tag name, but no other characters |
| 20:23 | <jgraham> | They are parse errors and ignored, but the tokenizer has to deal with them |
| 20:23 | <Ms2ger> | The authoring requirements and the actual parsing have no meaningful relation to eachother |
| 20:23 | <jgraham> | jsocol: The requirements on UAs are entirely unrelated to the requirements on authors |
| 20:23 | <Hixie> | yeah that's not a bug, that's intentional |
| 20:24 | <Hixie> | </foo bar baz> is treated as a single end tag |
| 20:24 | <jsocol> | let me rephrase |
| 20:24 | <Hixie> | for compat reasons |
| 20:24 | <jsocol> | oh compat reasons? |
| 20:24 | <jsocol> | I figured there was a reason |
| 20:24 | <Hixie> | (the "bar baz" part turns into "attributes", that are then dropped) |
| 20:24 | <Ms2ger> | It's a magic phrase |
| 20:24 | <Hixie> | pretty much everything the parser does is for compat reasons :-) |
| 20:24 | <Ms2ger> | Hixie says "compat reasons", everyone shuts up |
| 20:24 | <jgraham> | jsocol: The whole parser is basically a big tangle of compat constraints |
| 20:25 | <Hixie> | (btw you may find http://whatwg.org/html to be a better reference) |
| 20:25 | <jsocol> | the unfortunate consequence of using the same "tag name state" is that the parser does something non-obvious for authors |
| 20:25 | <Hixie> | (it's mostly the same text but is more likely to remain up to date) |
| 20:25 | <jgraham> | Hixie: Unrelatedly, when one spins the event loop waiting for a condition, it is only supposed to observe the condition at the end of tasks, right? |
| 20:26 | <Ms2ger> | jsocol, well, you've got an error |
| 20:26 | <Hixie> | jgraham: it checks for the conditions continually, but queues a task when it is met |
| 20:26 | <jgraham> | Hixie: Huh? |
| 20:26 | <Ms2ger> | jsocol, there are multiple ways to fix it up |
| 20:27 | <Hixie> | jgraham: which part of my statement was confusing? |
| 20:27 | <Ms2ger> | jsocol, I'm not sure if one of the DOMs you expected is more obvious than what we had to go with |
| 20:27 | <jgraham> | So if I have a script that temporarily causes a condition to be met, it thinks the condition has been met, even if it is never true at the end of the event loop? |
| 20:27 | <jsocol> | Ms2ger: the "correct" way is obviously not to have the error. but either of those seems entirely more obvious, as a web developer |
| 20:27 | <Ms2ger> | Then again, I've read some of the parsing algorithm... |
| 20:27 | <jsocol> | than a missing > cutting off an entire paragraph |
| 20:28 | <Ms2ger> | So, my definition of "obvious" may differ from the one used by sane peopl |
| 20:28 | <Ms2ger> | e |
| 20:28 | <Hixie> | jsocol: it's definitely not intuitive, i agree |
| 20:28 | <Hixie> | welcoem to html :-) |
| 20:28 | <jsocol> | heh :) |
| 20:30 | <jsocol> | at the risk of being "that guy" it seems like two new states would allow the parser to do something much more intuitive with unfinished end tags |
| 20:30 | <jsocol> | though there might be other analogous states needed elsewhere |
| 20:31 | <jgraham> | Hixie: For example, if I have a document with one inline resource loading which is delaying the load event and I run a script (e.g. from DOMContentLoaded) that stops that load and starts a new load, should onload be delayed by the new load? |
| 20:31 | <jgraham> | Or can that not happen for some reason? |
| 20:31 | <Ms2ger> | jsocol, the final remark in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029409.html is relevant :) |
| 20:32 | <jgraham> | (the only reason I can think that it might not be possible is if the "delay a load event" always happens in resposne to something async, so you always reach the end of the event loop with nothing blocking the load at least once) |
| 20:34 | <jsocol> | Ms2ger: heh ;) |
| 20:36 | <jsocol> | Ms2ger: to be fair, though, this isn't about aesthetics so much as Postel's law and trying to minimize the impact of a small error |
| 20:36 | <Ms2ger> | jsocol, the HTML parser is a textbook example of how Postel's law is fundamentally broken |
| 20:37 | <jsocol> | I don't think it's broken so much as "really hard" |
| 20:38 | <jsocol> | Ms2ger: anyway, politically, if I bring this up on the list, it'll just get shot down? I don't want to waste my time. |
| 20:38 | <Ms2ger> | Well |
| 20:38 | <Ms2ger> | Hixie already shot you down, pretty much :) |
| 20:39 | <jgraham> | Alternatively the HTML parser is a textbook example of how postel's law is necessary |
| 20:39 | <jgraham> | jsocol: The requirements on UAs here aren't going to change |
| 20:39 | <jsocol> | jgraham: fair enough. |
| 20:39 | <jsocol> | thanks for all your time |
| 20:39 | <jgraham> | In general we are *very* conservative with parser changes now that the main browsers are interoperable and the universe didn't end |
| 20:41 | <Hixie> | yeah i wouldn't expect the parser to change |
| 20:42 | <Hixie> | that ship has sailed |
| 20:42 | <gavinc> | Is DOM4 on the same 2014 time line for recomendation? |
| 20:42 | <Hixie> | i mean, not for intentional things like this |
| 20:42 | <gavinc> | sorry, same HTML5 timeline |
| 20:42 | <Hixie> | it will still change for bugs of course :-) |
| 20:42 | <Ms2ger> | gavinc, there's a timeline in the new WebApps charter |
| 20:42 | <Hixie> | gavinc: this may be the wrong channel for asking about the HTML5 timeline :-P |
| 20:42 | <jgraham> | People care about those timelines? |
| 20:42 | <Ms2ger> | It may or may not have any relation to reality |
| 20:43 | <Hixie> | jgraham: i think as written (from memory) it would not delay onload, but let me check |
| 20:43 | <Ms2ger> | gavinc, and the timeline for HTML5 is still rec in 2022 |
| 20:43 | <gavinc> | people writing another w3c recomendation which would like to refer to DOM 4 do indeed care |
| 20:43 | <Ms2ger> | Whatever the W3C may claim |
| 20:43 | <jgraham> | People writing other recommendations should do the right thing and reference DOM4 |
| 20:43 | <Hixie> | Ms2ger: unless they violate the process |
| 20:43 | <Hixie> | Ms2ger: which is likely to occur |
| 20:43 | <Ms2ger> | Which they will, of course |
| 20:43 | <jgraham> | It is a myth that you can't do that and advance your own recommendation |
| 20:44 | <Ms2ger> | jgraham, it's irrelevant what you reference anyway |
| 20:44 | <Ms2ger> | Also, meant for gavinc |
| 20:44 | <Ms2ger> | The keys are so close together |
| 20:44 | <gavinc> | It's a myth that W3C staff likes mentioning anytime I try to refrence something from Webapps or HTML WG ;) |
| 20:45 | <Hixie> | gavinc: tell them to get teh fuck out of the way |
| 20:45 | <Hixie> | gavinc: isntead of harming the web |
| 20:45 | <jgraham> | Well yeah, but it would be better to reference the thing that people should actually look at rather than hope people will realise you were just playing Process games |
| 20:45 | <gavinc> | I'm aware! |
| 20:46 | <Hixie> | gavinc: bureaucracy is opt-in. They can't make you do anything you don't want to do. |
| 20:46 | <jgraham> | Also, I am reasonably sure this particular requirement isn't really baked in anywhere |
| 20:46 | <gavinc> | Yes, but I'm hurting the web anyway working on RDF recomendations ;) |
| 20:46 | <Ms2ger> | Oh |
| 20:47 | <Ms2ger> | In that case, go away ;) |
| 20:47 | <Hixie> | lol |
| 20:47 | <Hixie> | ah well if you're working on RDF, then yeah, you definitely shouldn't go to REC until HTML5 is in REC in 2022. :-P |
| 20:47 | <Hixie> | (TR/ page is such a waste of time) |
| 20:48 | <gavinc> | Hey hey, at least XMLLiteral and a new HTML literal use the DOM as their value space |
| 20:56 | <Hixie> | can anyone sanity check this idea for me?: http://junkyard.damowmow.com/506 |
| 20:57 | <Hixie> | the algorithm is a bit busted |
| 20:57 | <Hixie> | but ignore that |
| 20:57 | <gavinc> | wouldn't it make sense to use the RFC uri template mechanisum too? |
| 20:57 | <Hixie> | lordy |
| 20:58 | <Hixie> | that seems like overkill |
| 20:58 | <jgraham> | Oh my. That's horribly ugly |
| 20:58 | <Hixie> | you reckon? |
| 20:58 | <a-ja> | question re: <dialog> -- i see there's a declarative way to close a dialog, but is there a declarative (i.e. scriptless) way to "open" a dialog? |
| 20:59 | <Hixie> | a-ja: there is not |
| 20:59 | <a-ja> | hrm |
| 20:59 | <Hixie> | what's your use case? |
| 20:59 | <gavinc> | also the pixal density is in terms of what? what exactly is 1? |
| 20:59 | <Hixie> | jgraham: ("you reckon?" being an honest question, not sarcasm, for the record) |
| 20:59 | <Hixie> | gavinc: 1 = 96dpi |
| 21:00 | <Hixie> | gavinc: device pixels per CSS pixel |
| 21:00 | <jgraham> | Inventing a whole templating microsyntax for a specific case of image loading seems pretty ugly, yes |
| 21:00 | <a-ja> | Hixie: e.g. opening a modal nav menu on mobile |
| 21:00 | <Hixie> | jgraham: it's not really a new syntax, it's just your regular substitution mechanism |
| 21:00 | <gavinc> | Hixie: oh, like -moz-device-pixel-ratio got it |
| 21:01 | <jgraham> | Hixie: From a UA point of view it is a new syntax, and needs special processing rules |
| 21:01 | <Hixie> | jgraham: i don't really care what the substitution syntax is if you have a better idea |
| 21:01 | <Hixie> | jgraham: but as far as i can tell the implementation is just three lines of code -- replace this string with this string, three times |
| 21:02 | <Hixie> | jgraham: very similar to addProtocolHandler()'s syntax |
| 21:02 | <gavinc> | Hixie: if one was going to introduce one, using the URI templates syntax wouldn't be a bad idea |
| 21:02 | <jgraham> | Hixie: You need to parse the src versions attribute and deal with invalid values |
| 21:02 | <Hixie> | jgraham: yeah, that's basically the "sizes" attribute with an extra axis |
| 21:02 | <Hixie> | gavinc: that's more complicated than just three substitutions |
| 21:03 | <jgraham> | and deal with unexpected % values in the filename template and so on |
| 21:03 | <Hixie> | nah you jus do the same as addPRotocolHandler() |
| 21:03 | <Hixie> | replace %w with width value if present. |
| 21:03 | <Hixie> | ditto h, d |
| 21:03 | <Hixie> | then resolve and fetch |
| 21:04 | <jgraham> | So you can't have the literal string %w in the image filename |
| 21:04 | <Hixie> | it would be invalid anyway |
| 21:04 | <jgraham> | and it only solves the use case where the only thing you care about is the physical image size, which people claimed wasn't enough |
| 21:04 | <Hixie> | i guess %d should be %r or something |
| 21:04 | <Hixie> | since we can't use a-f |
| 21:04 | <Hixie> | jgraham: how so? |
| 21:05 | <webben> | What's the declarative way to close a dialog? |
| 21:05 | <jgraham> | Hixie: What do you mean? |
| 21:05 | <Hixie> | jgraham: what doesn't it handle? |
| 21:05 | <Hixie> | (other than bandwidth isues) |
| 21:05 | <Hixie> | webben: <form method=dialog> <input type=submit> </form> |
| 21:05 | <Hixie> | webben: iirc |
| 21:05 | <webben> | ta |
| 21:06 | <jgraham> | Well bandwidth was one that people mentioned. I'm not sure if there were other device properties people cared about |
| 21:06 | <jgraham> | I would need to read the use cases again |
| 21:07 | <webben> | <form method=dialog action="#fragment-id-of-dialog"><input type="submit"></form> might work for opening |
| 21:07 | <Hixie> | there were various device properties people mentioned, e.g. input touch vs keyboard, but as far as image selection goes only bandwidth, available space, and pixel density were requested, at least in what i've read so far |
| 21:07 | <Hixie> | (still reading) |
| 21:08 | <a-ja> | webben: what Hixie said.....plus there some extra handling for input image coordinates |
| 21:08 | <Hixie> | gavinc: (do you have a link to the latest uri templating stuff so i can confirm or contradict my fears? i can't find a relevant link on google.) |
| 21:08 | <gavinc> | Hixie: http://tools.ietf.org/html/rfc6570 not -that- horrifying |
| 21:08 | <gavinc> | Not saying implement the whole thing |
| 21:08 | <gavinc> | but use it's syntax |
| 21:08 | <Hixie> | a-ja: i don't have an a priori objection to finding a way to open a dialog declaratively, but i'm not sure i really understand how it would work |
| 21:08 | <gavinc> | but use it's syntax |
| 21:08 | <Hixie> | a-ja: i don't have an a priori objection to finding a way to open a dialog declaratively, but i'm not sure i really understand how it would work |
| 21:09 | <gavinc> | on the other hand, implementing the whole thing would be generally useful ;) |
| 21:09 | <Hixie> | gavinc: if we used its syntax, you wouldn't be able to mix this stuff with templates later |
| 21:09 | Hixie | really isn't sold on uri templates in general, fwiw |
| 21:09 | <gavinc> | Hixie: Yeah, but that happens with tons of template syntax |
| 21:09 | Hixie | really isn't sold on uri templates in general, fwiw |
| 21:10 | <Hixie> | i really don't see any advantage to just making this look like uri templates, it would make people think it was related |
| 21:10 | <Hixie> | which is just confusing |
| 21:10 | <Hixie> | and would cause all kinds of trouble |
| 21:10 | Philip` | wonders if he's missed why you'd ever want to pass parameters inside the filename, instead of doing face.jpg?w=600&h=200&d=1 |
| 21:10 | <Hixie> | e.g. people asking for more of it to be implemented |
| 21:10 | <Hixie> | Philip`: static CDNs |
| 21:10 | <Hixie> | Philip`: but note that the proposal above supports query parameters too |
| 21:11 | <Hixie> | just do "face.jpeg?w=%w&h=%h&d=%r" |
| 21:13 | <gavinc> | "my%5Fface%5%w%5%h%5%r" gets a bit special |
| 21:13 | <Hixie> | you don't have to escape _ |
| 21:13 | <Hixie> | not sure what your %5s are |
| 21:14 | <gavinc> | err forgeting to type F |
| 21:14 | <webben> | Hixie: I guess in a-ja's case, menu items to open submenus would actually be dialog submit forms opening the appropriate dialog for the submenu. |
| 21:15 | <webben> | the submenu dialog would have a close form |
| 21:15 | <Hixie> | webben: ah, yeah, if you want a button to open another dialog... |
| 21:15 | <a-ja> | Hixie: i'm thinking link (possibly wrapping a button) to set a href'ed dialog's open attribute. |
| 21:15 | <webben> | so you could pop open or close the entire menu tree without any JS. |
| 21:15 | <Hixie> | yeah |
| 21:15 | <Hixie> | that wasn't really the use case i had in mind when designing this |
| 21:15 | <Hixie> | but it's an interesting use case |
| 21:16 | <Hixie> | if you have any examples (ideally with screenshots) of sites doing things like this, it would be great to document them (the screenshots) on the wiki and mail a link to the list |
| 21:16 | <gavinc> | So if your passing the value of src-template into somethat that does uri quoting... the UA would need to see face-%25w-%25h%40%25d.jpeg as being the same? |
| 21:16 | <a-ja> | Hixie: something that'd look like menu button at http://addons.mozilla.org/en-US/android/ |
| 21:16 | <Hixie> | gavinc: i don't understand the question |
| 21:16 | <gavinc> | or is src-template not really an URI so you can't really do quoting? |
| 21:16 | <Hixie> | gavinc: i don't understand the question |
| 21:17 | <Hixie> | a-ja: i don't see a button labled "menu" on that page |
| 21:17 | <gavinc> | if src-template does quoting than the replacement is not just %w but %25w and if it doesn't allow quoting it's a bit funky? |
| 21:18 | <Hixie> | what do you mean by "does quoting"? |
| 21:18 | <gavinc> | Can you use % quoted strings in it? |
| 21:18 | <Hixie> | it works the same as addProtocolHandler() |
| 21:18 | <Hixie> | the value is taken as a literal |
| 21:18 | <Hixie> | you do the substitutions |
| 21:18 | <Hixie> | then you resolve the URL |
| 21:18 | <gavinc> | ah |
| 21:18 | <Hixie> | then you fetch the image |
| 21:18 | <gavinc> | okay |
| 21:18 | <a-ja> | Hixie: top right.....maybe it looks different with UA-sniffing |
| 21:19 | <gavinc> | Hixie: So just have to make sure on a producers end that %w doesn't get quoted like % would otherwise |
| 21:19 | <Hixie> | a-ja: what browsers should i be testing with? |
| 21:19 | <Hixie> | gavinc: it's not a URL, right |
| 21:19 | <a-ja> | i'm using FF android nightly |
| 21:19 | <Hixie> | it's a pattern that created a URL |
| 21:20 | <Hixie> | a-ja: url to install that? :-) |
| 21:20 | <gavinc> | Hixie: producers need to make sure that it's quoted LIKE a URL except in some special way |
| 21:20 | <Hixie> | a-ja: got it |
| 21:20 | <a-ja> | k |
| 21:23 | <gavinc> | Hixie: also generally, what's the advantage of a template vs just providing a URL for each of the sizes? |
| 21:24 | <a-ja> | Hixie: looks pretty much same on stock browser (gingerbread) |
| 21:24 | <benvie> | there's no "official" .idl for html5 aside from what can be made from concatenating together the chunks from the actual spec itself right? |
| 21:24 | <benvie> | just want to make sure I'm not missing something obvious |
| 21:24 | <benvie> | there's no "official" .idl for html5 aside from what can be made from concatenating together the chunks from the actual spec itself right? |
| 21:24 | <benvie> | just want to make sure I'm not missing something obvious |
| 21:24 | <gavinc> | eg.. src-600x200x2 src-600x200x1 src-200x200x1 |
| 21:26 | <Hixie> | right, got that installed |
| 21:26 | <Hixie> | let's look at this page now |
| 21:26 | <gavinc> | Hixie: or src-sized="200x200x1:blah.jpg" |
| 21:27 | <Hixie> | benvie: correct |
| 21:27 | <Hixie> | gavinc: the browser needs to know what the values are so it can pick the right one |
| 21:28 | <Hixie> | a-ja: that menu doesn't seem modal |
| 21:28 | <Hixie> | a-ja: just looks like a regular menu to me |
| 21:28 | <annevk> | gavinc: which draft are you editing? |
| 21:28 | <Hixie> | a-ja: for which i'd recommend <menu>, not <dialog> |
| 21:28 | <annevk> | oh RDF |
| 21:28 | <annevk> | :) |
| 21:29 | <gavinc> | annevk: sigh ... thanks :P http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html |
| 21:30 | <annevk> | jgraham: the protocol handler stuff has substitution |
| 21:30 | <gavinc> | Hixie: Right, so if it can read the sizes from an attribute, why can't it read the sizes AND the URL from an attribute? |
| 21:30 | <annevk> | I should read everything first, all my questions appear addressed |
| 21:30 | <gavinc> | Hixie: What does the template gain? |
| 21:31 | <annevk> | or maybe just continue playing Portal 2 |
| 21:31 | <benvie> | Thanks. I've included the resulting IDL in a thing I made and included references to the source for all IDLs included, so I wanted to make sure I was referencing the right thing. Resulting JSON is here https://github.com/Benvie/idl-for-javascript/blob/master/json/html5.json |
| 21:33 | <annevk> | gavinc: you already reference HTML5, HTML5 references DOM4, problem solved |
| 21:34 | <gavinc> | annevk: Yes, I shall make this argument some more :D |
| 21:34 | <gavinc> | but yay no more required XML-C14N! |
| 21:35 | <annevk> | now you just need to get rid of that RDF reference and it might start to look sane :p |
| 21:37 | <a-ja> | Hixie: i could see using menu....but it wouldn't have same flexibility (positioning/fullscreen/background) that dialog has. that case can actually be done w/o script now (cept for aria) |
| 21:37 | <a-ja> | with overlays |
| 21:37 | <Hixie> | gavinc: some people want urls like just banner-200 banner-640 banner-2800 banner-4960 |
| 21:38 | <Hixie> | gavinc: others want urls like banner.jpeg?w=200&h=400 |
| 21:38 | <Hixie> | gavinc: others want urls like banner⊙2 |
| 21:38 | <gavinc> | Hixie: ... yes... I'm saying PUT the WHOLE URL in the attribute |
| 21:38 | <Hixie> | gavinc: oh and repeat the common part over and over? |
| 21:38 | <Hixie> | gavinc: and repeat the dimensions twice, once for the url and once for the value for the browser to know what it is? |
| 21:39 | <gavinc> | Hixie: src-600x200x2="mine_600_200_2.jpg" |
| 21:39 | <gavinc> | Hixie: Yep, 'cause what if there isn't a common part? |
| 21:39 | <Hixie> | gavinc: that seems really verbose |
| 21:39 | <gavinc> | Hixie: or it's just 600x200x2="larger.jpg" |
| 21:40 | <annevk> | Hixie: do we need anything more than x1 and x2 in practice? |
| 21:40 | <gavinc> | Hixie: src-600x200x2="higher-res.png", 200x100x1="tiny.gif" |
| 21:40 | <Hixie> | annevk: different widths |
| 21:40 | <gavinc> | Hixie: If it's templated you have to use the same image format for each size |
| 21:40 | <annevk> | Hixie: hmm |
| 21:41 | <Hixie> | gavinc: seems better to push the people using those kinds of filenames towards filenames that use a pattern, than force authors who do use a pattern to not gain anything from doing so |
| 21:41 | <Hixie> | gavinc: why? |
| 21:41 | <gavinc> | Hixie: well, or you have to not use file extentions, which people seem rather loth to give up |
| 21:42 | <Hixie> | gavinc: or they can just use whatever file extensions they like, the browsers ignore them anyway :-P |
| 21:42 | <gavinc> | Hixie: Yes, but that way lies crazy |
| 21:42 | <annevk> | at this point not really |
| 21:43 | <annevk> | determining the image type from the file signature is extremely reliable |
| 21:43 | <gavinc> | Hixie: Saving a .png to my desktop that was an image/jpeg is a bit funky |
| 21:43 | <annevk> | and way better than using Content-Type |
| 21:43 | <gavinc> | Hixie: Just saying, there isn't a NEED for templating. Can do exactly the same thing by just requiring the full URL |
| 21:45 | <llrcombs> | so, is CORS an official standard now? |
| 21:45 | <llrcombs> | The xkcd.com sysadmin wants to know |
| 21:45 | <llrcombs> | it was a last call draft expiring on may 1st; I dunno if there were complaints or not |
| 21:46 | <othermaciej> | that depends on what counts as an "official standard" |
| 21:46 | <othermaciej> | it is implemented in many browsers |
| 21:46 | <othermaciej> | it is officially on the W3C Recommendation track |
| 21:46 | <llrcombs> | accepted as standard by W3C, I think |
| 21:46 | <othermaciej> | it has not yet reached the final "Recommendation" state |
| 21:46 | <annevk> | xkcd uses XHTML 1.1 |
| 21:46 | <annevk> | sent as text/html |
| 21:46 | <othermaciej> | on the other hand, nearly nothing you actually use is a W3C Recommendation |
| 21:46 | <annevk> | doesn't seem they care much about standards :p |
| 21:47 | <llrcombs> | othermaciej: I'm not the sysadmin, I'm asking because he wants to know on another server |
| 21:47 | <annevk> | llrcombs: CORS is implemented by all browsers, big sites use, it's not going to change |
| 21:47 | <annevk> | llrcombs: xkcd.com using it would further cement it |
| 21:48 | <Hixie> | gavinc: sure, there's many ways we can make this more verbose and annoying :-P |
| 21:48 | <annevk> | llrcombs: as far as W3C games go, it might become a Candidate Recommendation soonish, depending on how soon I get around to making some edits |
| 21:48 | <Hixie> | gavinc: some of the proposals on the thread even involve multiple new elements and fallback hierarchies |
| 21:50 | <othermaciej> | llrcombs: well, I gave you all the relevant info I have, I am not sure what you or he would consider to be an official standard though |
| 21:50 | <llrcombs> | othermaciej: well, I'll accept it as standard at this point; not sure if he will. I've passed on the info, though |
| 21:50 | <othermaciej> | llrcombs: if his real question is "should I use it", then the answer is "totally yes, it's in multiple browsers and highly interoperable" |
| 21:51 | <othermaciej> | the chances of it being removed from the standards track or changed incompatibly are very low |
| 21:51 | <annevk> | Hixie: http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html is what's proposed for CSS which is much simpler |
| 21:52 | <annevk> | Hixie: it doesn't address your width use case and dunno if the CSS WG bikeshedded it into something more complex |
| 21:52 | <annevk> | llrcombs: is he also in charge of the HTML? because sending XHTML as text/html is doubtful as far as following standards goes |
| 21:53 | <llrcombs> | annevk: he says he does that because it's better supported by some browsers |
| 21:53 | <llrcombs> | not sure how |
| 21:53 | <llrcombs> | lemme just copy |
| 21:53 | <annevk> | [citation needed] |
| 21:53 | <annevk> | anyway, I don't care, awesome comics are readable either way |
| 21:53 | <llrcombs> | <davean> llrcombs: the standard specifies sending XHTML as text/html is acceptable <davean> llrcombs: And it works better and we should be satisfying the compatability rules |
| 21:55 | <annevk> | http://www.w3.org/TR/xhtml-media-types/#text-html |
| 21:56 | <annevk> | I guess if you want to use XHTML and not HTML and still somehow work with IE you do want text/html indeed |
| 21:56 | <webben> | XHTML 1.1 as text/html? 2009 wants its boring debates back. |
| 21:56 | <annevk> | webben: more like 2004 |
| 21:56 | <llrcombs> | I do believe it satisfies appendix A, but I'm not sure. If you really care, ask at #xkcd on foonetic |
| 21:56 | <othermaciej> | Hixie: I think an <img> attribute that takes similar syntax to the proposed CSS image-set would be a fine solution |
| 21:57 | <gavinc> | and make it Ployglot, 'cause making it Ployglot is so much fun |
| 21:57 | <annevk> | when <template> is there XML is over |
| 21:57 | <othermaciej> | Hixie: it can be in addition to src, so fallback works |
| 21:58 | <othermaciej> | Hixie: and presumably the same thing for any other content attributes that reference an image, not sure what the full set of those is (at least <video poster> I guess) |
| 21:58 | <annevk> | assuming <template> is going to be widely adopted and used |
| 21:58 | <llrcombs> | what's <template>? |
| 21:58 | <annevk> | othermaciej: <link rel=icon> |
| 21:58 | <annevk> | othermaciej: oh wait that already has a syntax |
| 21:59 | <gavinc> | othermaciej: I was unaware of image-set! Yes! That on <img>! That's clearly what I meant ;) |
| 21:59 | <othermaciej> | annevk: that has a syntax to represent different sizes, and I suspect scale as separate from size is irrelevant |
| 21:59 | <annevk> | llrcombs: feature primarily for "web components" |
| 22:00 | <othermaciej> | annevk: (because icons are most likely rendered at a visible size chosen by the UA independent of intended scales of the underlying images) |
| 22:01 | <llrcombs> | link to spec? |
| 22:01 | <annevk> | llrcombs: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html |
| 22:02 | <othermaciej> | Hixie: anyway you should definitely consider <http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html>; as part of input for this, it even suggests an HTML syntax, though we have only implemented the proposed CSS syntax in WebKit so far |
| 22:02 | <llrcombs> | that's helpful. I'll read up later. Thanks! |
| 22:35 | <Hixie> | othermaciej: image-set? |
| 22:36 | <Hixie> | othermaciej: oh the 1x 2x thing? |
| 22:36 | <othermaciej> | Hixie: I'm not sure what you are asking about image-set, but my answer is probably "yes" (assuming it is a yes/no question) |
| 22:36 | <Hixie> | othermaciej: my question was "what is image-set", but your later link cleared that up |
| 22:36 | <Hixie> | othermaciej: people also want to be able to handle different available widths and heights |
| 22:36 | <Hixie> | widths mainly |
| 22:36 | <Hixie> | e.g. banner on narrow window vs banner on fullscreen tablet |
| 22:38 | <othermaciej> | Hixie: I see - not sure how to handle that one |
| 22:38 | <othermaciej> | Hixie: CSS media queries can handle things like screen size of course, but don't apply to content images |
| 22:38 | <othermaciej> | replicating the full CSS media query syntax would be a bother |
| 22:39 | <Hixie> | othermaciej: yeah |
| 22:39 | <othermaciej> | I suspect people serving different image widths for different screen widths often want to do additional adaptation to the layout, so a technique for dealing with just the images may have less value |
| 22:39 | <Hixie> | othermaciej: what i'm proposing (See junkyard link earlier) is close to what image-set is doing |
| 22:39 | <Hixie> | well, the layout can be adapted in css |
| 22:40 | <Hixie> | the point is there are some content-level images that would also need to be adapted |
| 22:40 | <Hixie> | and it'd be sad to have to have the css replace the content-level images |
| 22:41 | <othermaciej> | Hixie: forcing a fixed naming convention seems like a significant limitation with little upside |
| 22:41 | <othermaciej> | Hixie: images for different resolutions might not even be served from the same host |
| 22:41 | <Hixie> | that seems unlikely |
| 22:42 | <othermaciej> | Hixie: for the width thing, I guess you can set the layout width of the <img> with a CSS media query and then use your algorithm to pick the source, otherwise it seems unlikely to be helpful |
| 22:42 | <othermaciej> | Hixie: I suspect Apple Web properties will in many cases want to vary by device pixel ratio but not by available screen width, does your proposal provide for that? |
| 22:43 | <Hixie> | yes |
| 22:43 | <Hixie> | see link above |
| 22:43 | <othermaciej> | I looked at http://junkyard.damowmow.com/506 and it's not obvious |
| 22:43 | <Hixie> | it uses width, height, and pixel density |
| 22:43 | <othermaciej> | do you have to specify the width and height and put it in the image name even if you don't want to vary on it? |
| 22:44 | <Hixie> | no, you could just use foo@%r.jpeg to use foo⊙1 or foo⊙2 |
| 22:44 | <othermaciej> | and what do you put in src-versions? |
| 22:44 | <Hixie> | i guess you do have to specify a dimension in the sec-versions attributes |
| 22:44 | <Hixie> | src-versions |
| 22:45 | <othermaciej> | I think authors for the "resolution adaptation only" use case will not want to mention dimensions in the markup |
| 22:45 | <Hixie> | yeah, that's valid |
| 22:45 | <Hixie> | in many of hte examples i saw, there were many images with filenames that had all the same data as the dimensions |
| 22:46 | <Hixie> | it seems really sucky to require those authors to duplicate all that data |
| 22:46 | <othermaciej> | and I think that use case will be more common than the width adaptation use case |
| 22:46 | <Hixie> | i think they're both common enough to be addressed directly |
| 22:47 | <othermaciej> | I might have a non-representative sample of developer requests |
| 22:47 | <othermaciej> | but I have heard lots of requests for resolution adaptation and none for width adaptation (on an image-by-image basis) |
| 22:47 | <othermaciej> | not even on the CSS side |
| 22:48 | <othermaciej> | but my point was only that width adaptation should not make resolution adaptation alone more complicated |
| 22:48 | <othermaciej> | (more complicated to use) |
| 22:49 | <othermaciej> | we do have some limited testing/deployment experience with image-set in CSS and authors seem to like it |
| 22:49 | <othermaciej> | in some cases authors objected to a fixed filename pattern solution, though I don't know that we ever proposed an adaptable name template as you have it |
| 22:50 | <othermaciej> | in current deployment I think there are cases where the 1x name is undecorated and the 2x name has @2x appended before the extension |
| 22:52 | <Hixie> | yeah |
| 22:53 | <Hixie> | i'd love to support a way to support separate names while still not requiring duplication |
| 22:55 | <othermaciej> | I think you'd need to support author choice of either a list or the template thing to support both |
| 22:56 | <othermaciej> | I can't think of an obvious way to unify other than that |
| 23:01 | <Hixie> | yeah |
| 23:01 | <Hixie> | me either |
| 23:01 | <Hixie> | doing both seems lame |
| 23:02 | <gavinc> | the list covers all the uses cases but requires some duplication, the template doesn't support as many use cases |
| 23:03 | <Hixie> | right |
| 23:03 | <Hixie> | supporting more use cases isn't always a win if the result is less usable overall |
| 23:04 | <Hixie> | often the key to language design is figuring out which use cases to forsake |
| 23:05 | <annevk> | the only thing I have seen suggested thus far is resolution |
| 23:06 | <Hixie> | a lot of the e-mails on whatwg discussed image dimensions |
| 23:06 | <annevk> | oh, I guess some have suggested width as well, but I'm not sure that's quite as valid |
| 23:06 | <Hixie> | in fact that was discussed long before pixel density |
| 23:06 | <gavinc> | annevk: I mean for example one image on one server and the other image on another, the template method can't support that at all |
| 23:06 | <Hixie> | (the concern being a page that displays on a tiny mobile display and a huge desktop display) |
| 23:07 | <annevk> | tiny mobile display does not really exist anymore though |
| 23:07 | <Hixie> | o_O |
| 23:08 | <Hixie> | i can fit about 45 phone screens the size of my phone in the space of my desktop's screen :-P |
| 23:08 | <annevk> | most desktop sites render fine on my phone |
| 23:09 | <annevk> | and pixel wise they are not too different, although I guess that might change |
| 23:10 | <gavinc> | annevk: err, at css pixal size they (read iPhone) are still small |
| 23:11 | <annevk> | sure, but you also hold it closer to you, so it sort of works out, especially combined with zooming |
| 23:13 | <annevk> | it would be interesting to know how many sites try to accomplish the different image for mobile and desktop but the rest remains the same today |
| 23:13 | <annevk> | because it seems a rather obscure case |
| 23:14 | <Hixie> | dude if you send my 1280x720 phone a 2560x1440 picture, you're wasting a lot of pixels |
| 23:14 | <annevk> | whereas providing high resolution images without messing with bandwidth usage for lower resolution devices seems like something everyone wants to do |
| 23:14 | <Hixie> | but if you send my 2560x1440 desktop a 1280x720 picture, you're gonna find it doesn't fit my screen |
| 23:15 | <Hixie> | (both are 96dpi-equivalent displays) |
| 23:17 | <annevk> | that's what often ends up happening when browsing reddit and it doesn't matter that much :) |
| 23:19 | <Hixie> | a lot of web authors seem to disagree about it not mattering |
| 23:21 | <Hixie> | hober: (did you ever mention http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html on whatwg btw?) |
| 23:26 | <Hixie> | anyone know off-hand what ascii punctuation characters aren't allowed anywhere in a URL? |
| 23:29 | <Hixie> | damnit, commas are valid in URLs |
| 23:33 | <Hixie> | http://junkyard.damowmow.com/507 |
| 23:34 | <Hixie> | othermaciej, annevk, gavinc, hober: ^ |
| 23:35 | <annevk> | why do you pick the widest if they're all too wide and not the least wide? |
| 23:35 | <Hixie> | oversight |
| 23:36 | <othermaciej> | Hixie: seems good in general, though I'm not totally sure all details of the algorithm are right (why drop ones w/ no width when sorting by width?) |
| 23:36 | <annevk> | also, if you split on comma first, you can allow omitting everything |
| 23:36 | <Hixie> | othermaciej: i don't know what to do with the other ones |
| 23:36 | <Hixie> | annevk: can't split on comma, urls can have commas |
| 23:36 | <Hixie> | annevk: so have to parse more carefully |
| 23:37 | <annevk> | "," is a reserved character afaik |
| 23:38 | <gavinc> | yeah, "," is reserved |
| 23:38 | <Hixie> | it's a sub-delim, allowed in various places in urls |
| 23:38 | <Hixie> | e.g. anywhere in the path |
| 23:38 | <annevk> | yeah sorry |
| 23:38 | <gavinc> | mmm, yeah and a complex grammar to find them likely isn't worth while |
| 23:39 | <Hixie> | easy enough to walk the string bit by bit |
| 23:39 | <annevk> | but just like spaces sometimes have to be escaped, you could require it to be escaped here, but more complicated parsing works too I guess |
| 23:39 | <annevk> | I wonder how the image-set parsing is defined |
| 23:39 | <Hixie> | url(...) |
| 23:40 | <annevk> | oh right |
| 23:40 | <gavinc> | could require , |
| 23:40 | <gavinc> | err |
| 23:40 | <gavinc> | comma followed by whitespace |
| 23:40 | <gavinc> | but nah |
| 23:41 | <annevk> | Hixie: overall looks much better than the previous proposal |
| 23:41 | <Hixie> | this is basically hober's proposal slightly extended |
| 23:41 | <Hixie> | i can't claim credit :-) |
| 23:42 | <annevk> | hober's asleep, if you act quick the internet will never know |
| 23:42 | <Hixie> | hah |
| 23:42 | <annevk> | speaking of which, nn everyone |
| 23:42 | <Hixie> | nn |
| 23:49 | <Hixie> | ok i guess i'll spec this out tomorrow |
| 23:50 | <Hixie> | need to speak to hober about naming of the attribute |
| 23:50 | <Hixie> | set="" is kinda lame |
| 23:53 | <Hixie> | bbiab. if anyone wants to bikeshed the set="" attribute name post it here |