| 00:07 | <MikeSmith> | dglazkov: I set a cron job to check the dvcs.w3.org web server and restart it if it's down |
| 00:08 | <MikeSmith> | and which also sends a naggy message on IRC to the systems team and me each time it restarts it |
| 00:11 | <ojan> | cheesze0 |
| 00:11 | <ojan> | lol |
| 00:11 | <ojan> | now everyone knows my sc2 password |
| 00:11 | <TabAtkins> | brb, hacking ojan's sc2 |
| 00:11 | <ojan> | i should write a chrome extension that never lets me type my password |
| 00:11 | <TabAtkins> | gonna ruin his ladder ranking |
| 00:12 | <ojan> | sigh...i suppose i have to change it now |
| 00:12 | <TabAtkins> | (not sure if we're in a ladder freeze right now or not) |
| 00:21 | <dbaron> | I'm puzzled by the multiple one-letter-on-a-line patterns from tantek given how he was talking about how great his keyboard is. |
| 00:24 | <tantek> | sometimes there's even two letters |
| 00:26 | <TabAtkins> | There's 3 letters in the "escape" one up above. |
| 00:26 | <TabAtkins> | Crazy! |
| 00:26 | <tantek> | :) |
| 00:30 | <jamesr_> | ojan_away, if sc2 allows it, prefix your password with "/!" and your IRC client won't let it go out to channels |
| 00:39 | <Wilto> | Hey WHATWG, I’m here to apologize. |
| 00:40 | <Wilto> | My frustration with processes and such turned into outright hostility at points, and for that I am sorry. |
| 00:41 | <TabAtkins> | Hey Wilto! |
| 00:41 | <Wilto> | Yo. |
| 00:41 | <TabAtkins> | Happy we're all back to useful work. ^_^ |
| 00:42 | <Wilto> | This intrinsic width thing—the more I think about it, the more I think it may have been staring us in the face the whole time. |
| 00:43 | <Wilto> | If an author wants a fixed-width image at 1.5x resolution, wouldn’t height and width attributes solve that neatly? |
| 00:43 | <TabAtkins> | I think the intrinsic width part isn't very important. If you want a fast load you have to give @width and @height anyway, or else you'll produce extra layouts as images gets downloaded. |
| 00:43 | <Wilto> | Meanwhile, authors implementing flexible images with `max-width: 100%` could remove them; no harm, no foul. |
| 00:44 | <TabAtkins> | The fact that the "Nx" modifier changes the intrinsic is thus a good detail, but not an important one. |
| 00:44 | <TabAtkins> | The important bit of the "Nx" component is allowing UAs to decide which one to download, is all. |
| 00:45 | <Wilto> | This isn’t a defense, but wouldn’t `picture` with a height and width attribute make the pixel density MQ viable again? |
| 00:45 | <TabAtkins> | Nope, it doesn't change the reasoning in my blog post. |
| 00:46 | <Wilto> | Bandwidth? |
| 00:47 | <TabAtkins> | That's the whole reasoning for the "Nx" component, yes. |
| 00:48 | <Wilto> | So the idea is that bandwidth detection on the UA side would override the resolution set by the author, yeah? |
| 00:48 | <Wilto> | I’m not baiting you or anything; I’m actually just getting caught up after a few days. |
| 00:48 | <zewt> | jesus christ https://www.khronos.org/webgl/public-mailing-list/archives/1205/msg00199.html |
| 00:48 | <zewt> | The sooner we can achieve media type registration, the sooner interoperable Web-harmonious WebGLSL web services and serialization formats can be deployed and independent developers can build on the common type name. |
| 00:49 | <Wilto> | zewt: ABOUT TIME no I have no idea what any of that means |
| 00:49 | <TabAtkins> | Not quite. The idea is that, once you trim down the images that are invalid according to the width/height components, the browser is then free to use whatever metrics they want to choose between resolutions. |
| 00:49 | <TabAtkins> | So that they can, for example, forgo the high-res image on a 1x screen, or if on a low-bandiwdth connection. |
| 00:51 | <Wilto> | TabAtkins: Couldn’t we just apply that same line of reasoning to media queries? If on low bandwidth, ignore the `source` that matches an explicitly-defined resolution higher than X? |
| 00:51 | <TabAtkins> | Wilto: Not without changing the way that one MQ works, incompatibly with the way that MQs work in general. |
| 00:52 | <Wilto> | I feel like we’re circumventing the author’s intent in either case—which is perfectly logical. |
| 00:53 | <TabAtkins> | Right, it's not a problem of intent. We know what we want to do. It's a problem of purity. That's normally a very low concern, but when you have an equally-powerful solution that doesn't require confusing up the issue, it's better. |
| 00:53 | <Wilto> | Are we operating under the assumption that the UA will always make these decisions, or that there’ll be a “low bandwidth” setting or somesuch that kicks this logic into play? |
| 00:53 | <TabAtkins> | For example, if we use the "device-pixel-ratio" MQ for this use-case, and we define that it can be ignored sometimes, does that apply to general CSS as well? |
| 00:54 | <Wilto> | I feel like we have some wiggle room where there’s not much precedent for this in markup, and something like that would play _very_ well with `video` sources. |
| 00:54 | <Wilto> | I mean, they’re much more bandwidth-intensive, and a solution that covers both as outlined above would be pretty amazing. |
| 00:55 | <TabAtkins> | For video sources we probably want a somewhat more custom solution too, since you want to choose *not* on the attributes of the device, but on the attributes of the stream. |
| 00:55 | <Wilto> | You could make a case that CSS is another beast altogether, I suppose. “This is how things work with `media` attributes.” |
| 00:55 | <TabAtkins> | Yeah, that's confusing. ^_^ Best to avoid it if we can. |
| 00:56 | <Wilto> | I don’t know. Otherwise, we have “this is how things work with images, this with video, and this with CSS.” |
| 00:56 | <TabAtkins> | Really, the issue is just that you're not *actually* caring about the device's capabilities (or rather, you care about a much wider range of things than just the device's pixel ratio, many of which can't be exposed via MQ). You care about some qualities of the image. |
| 00:56 | <Wilto> | Again: not going on the offensive, here. Just throwing that out there. |
| 00:56 | <TabAtkins> | Wilto: Don't worry, I'm not interpreting you as hostile. |
| 00:57 | <zewt> | in my experience, trying to forcibly overgeneralize solutions to things that aren't really the same problem is one of the most common reasons for things being overcomplex and awkward |
| 00:57 | <zewt> | maybe images and video can be done the same way; but be careful not to assume it |
| 00:58 | <Wilto> | No, but that `media` attribute pattern already exists for this purpose. It’s far from ideal, but maybe “responsive images” is an opportunity to improve that to everyone’s benefit. |
| 00:58 | <TabAtkins> | Yeah. Reuse when possible, but don't be afraid to do custom solution when called for. If you have to invent new processing behavior in your new context, it's not really "reusing", it's just "borrowing syntax". |
| 00:59 | <TabAtkins> | Wilto: The @media attribute in video's <source> doesn't seem to actually be very useful, and its removal is being discussed. |
| 00:59 | <TabAtkins> | What you *actually* want to do with video sources is negotiate based on bitrate/size/etc. |
| 01:00 | <TabAtkins> | I don't think there's a strong argument to vary the video based on window width/height, like there is for images. |
| 01:01 | <Wilto> | Well, you could make a case that it isn’t used much where we can’t use it, but I see your point. |
| 01:02 | <TabAtkins> | I'll just say that I find it *very* unlikely that sites would generally record multiple videos for different screen sizes. ^_^ |
| 01:02 | <Wilto> | But having worked on video in a flexible layout, I wish the hell we could. |
| 01:03 | <zewt> | TabAtkins: having separate eg. 720p and 1080p videos is pretty reasonable |
| 01:03 | <zewt> | it'd see much less use than images, though, since it's a lot more expensive |
| 01:03 | <Wilto> | Yeah. We had a handful of videos in play on the Boston Globe site. |
| 01:03 | <TabAtkins> | zewt: Those aren't different sizes, though, right? Different res streams are useful to present, but don't seem to be tied to screen size strongly. |
| 01:04 | <zewt> | sure it is: serve a 720p video to people with a 720p display, 1080p to 1080p |
| 01:05 | <TabAtkins> | zewt: But again, a 720p screen isn't strongly tied to screen size, is it? |
| 01:05 | <zewt> | not the use case I'm talking about |
| 01:06 | <zewt> | 720p for a 720p display, regardless of the screen size |
| 01:06 | <TabAtkins> | Yes yes, that's fine. That's not waht I was talking about. Since you were responding to me talking about multiple screen sizes, I assumed you were talking about the same thing. |
| 01:06 | <zewt> | i'm talking about fullscreen video, where the screen size doesn't matter |
| 01:07 | <TabAtkins> | Okay, sure. I agree. ^_^ |
| 01:07 | <zewt> | (but there are a lot of other parameters to selecting a video, which may change while the video is playing, which is complex) |
| 01:07 | <TabAtkins> | No one's disagreeing that serving multiple res streams is useful. YouTube offers a strong existence proof that it's a good use-case. |
| 01:08 | <zewt> | eg. changing bitrate if the user's stream or CPU can't keep up with the one that was selected--that's pretty severely different from anything static images have to deal with |
| 01:09 | <TabAtkins> | It's kinda similar to a browser deciding "okay, the radio's still awake but nothing's used it for a second, so I can start downloading the hi-res versions of these images now". |
| 01:09 | <TabAtkins> | At least, from the authoring standpoint it's similar, and in broad strokes it's similar from the UA perspective too. |
| 02:02 | <heycam> | MikeSmith, did the certificate on dvcs.w3.org just change? only just got a warning about it now, although I see that it was issued a couple of weeks ago |
| 02:02 | <MikeSmith> | heycam: not as far as I know |
| 02:03 | <heycam> | hmm |
| 02:03 | <MikeSmith> | I seem to recall getting warnings about that for a while now, depending on the UA |
| 02:04 | <MikeSmith> | hmm and now it just seems to be hanging |
| 02:04 | <heycam> | MikeSmith, this is what I got just before: http://pastebin.mozilla.org/1647715 |
| 02:05 | <MikeSmith> | I see |
| 02:05 | <MikeSmith> | also see "remote: abort: HTTP Error 500: Cannot allocate memory" |
| 02:05 | <heycam> | yeah, that doesn't look good |
| 02:06 | <MikeSmith> | Swap: 524280k total, 437012k used, 87268k free, 16068k cached |
| 02:59 | <niftylettuce> | is there a way to specify a webkit location in the /temporary folder for FileEntry API for an <input type="file" /> somehow? |
| 02:59 | <niftylettuce> | e.g. <input type="file" temporaryfile="true" src="http://somesite.com/temporary/somefile.png"; /> |
| 03:44 | <niftylettuce> | rather, is there a way to append File Objects to forms? |
| 03:45 | <niftylettuce> | without XHR |
| 05:09 | <MikeSmith> | heycam: I still can't reproduce that cert error |
| 05:10 | <heycam> | MikeSmith, ok -- it seems to have gone away for me now too |
| 05:10 | <heycam> | MikeSmith, I wonder if the HTTP response was truncated due to the memory problem and that caused the cert error |
| 05:10 | <MikeSmith> | ah yeah |
| 05:10 | <MikeSmith> | perhaps |
| 05:10 | <Von_Davidicus> | Heyo, all. |
| 05:11 | <MikeSmith> | heycam: I will try to get some more swap space on that machine. I think that's what's causing the problems |
| 05:11 | <heycam> | MikeSmith, ok cool, thanks for looking into it |
| 05:18 | <Von_Davidicus> | Question about HTML5: Will there be a mechanism to let elements be selected in JavaScript via -class-? |
| 05:19 | <heycam> | can you use IRIs in CSS url() notation? |
| 05:20 | <zewt> | "IRI"? is that just to add to the URL/URI fun |
| 05:20 | <zewt> | heh |
| 05:20 | <heycam> | yeah haven't you heard of it? :) |
| 05:21 | <zewt> | no :0 |
| 05:21 | <zewt> | also :) |
| 05:21 | <heycam> | http://annevankesteren.nl/2005/02/iri |
| 05:22 | <zewt> | The thing is, the 1.0.1 release of Firefox is scheduled for this or maybe next week. |
| 05:22 | <zewt> | sounds contemporary :) |
| 05:22 | <heycam> | :p |
| 05:22 | <Von_Davidicus> | *Checks* Apparently URIs are limited to ASCII characters, while IRIs are intended to work with anything. |
| 05:22 | <zewt> | i don't even bother trying to distinguish URL/URI; nobody cares and I just say URL |
| 05:31 | <zcorpan> | heycam: css3-syntax seems to tokenize it at least |
| 05:33 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1536 and browsers accept it |
| 05:33 | <heycam> | zcorpan, oh as part of the tokeniser. didn't realise CSS had a html-spec-like tokeniser actually! |
| 05:33 | <zcorpan> | it didn't until recently |
| 05:36 | zcorpan | wonders what happens with lone surrogates in url() |
| 05:36 | <heycam> | I think http://dev.w3.org/csswg/css3-values/#urls doesn't exactly say to interpret the URI token as a URI rather than anything else |
| 05:38 | <Von_Davidicus> | Hello, hasather. |
| 05:41 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1537 - why is the ") }" missing in the DOM view in chrome? |
| 05:46 | <zcorpan> | Hixie: live dom viewer throws in encodeURIComponent when using unpaired surrogates |
| 05:46 | <zcorpan> | i'm surprised all browsers agree to throw for that case |
| 05:46 | <zcorpan> | (well haven't tested ie, but anyway) |
| 05:49 | <zcorpan> | seems chrome U+FFFDs a lone surrogate in url() |
| 05:52 | <Von_Davidicus> | ... which character is that? |
| 05:52 | <zewt> | fffd seems much more sane than a really obscure exception |
| 05:56 | <zcorpan> | zewt: the exception was unrelated :-) |
| 05:56 | <zcorpan> | Von_Davidicus: REPLACEMENT CHARACTER |
| 05:56 | <zewt> | unicode is A VERY LOUD STANDARD |
| 05:57 | <zcorpan> | yes, obviously characters are so important they have to be all-uppercase |
| 05:57 | <zewt> | can we have a movement or riot or something to eliminate screaming caps MUST from all standards |
| 05:57 | <zewt> | yes, it's a requirement, we get it, STOP YELLING AT ME |
| 05:57 | <heycam> | small caps works |
| 05:58 | <zewt> | it's ugly and jarring and unnecessary |
| 05:58 | <zewt> | html does just fine without it :) |
| 05:58 | <zcorpan> | i prefer lowercase, though i get much more worked up about specs that just suck |
| 05:58 | <zewt> | well, it'd take more than a riot to make all specs not suck |
| 05:58 | <zewt> | gotta have reasonable goals |
| 05:59 | <Von_Davidicus> | Sorry, small caps do not work for me. I prefer hats that fit properly. |
| 05:59 | <zcorpan> | that's it! give hats to all musts! |
| 05:59 | <zewt> | ____ |
| 05:59 | <zewt> | must |
| 05:59 | <zcorpan> | what's the code point for a hat? |
| 06:00 | <heycam> | I was gonna go with mûst |
| 06:03 | <zcorpan> | U+2229 |
| 06:03 | <zcorpan> | oh, here we go! U+1F3A9 |
| 06:04 | <zcorpan> | also U+1F452 |
| 06:05 | <zcorpan> | one hat for male requirements and one for female requirements |
| 06:06 | <zcorpan> | maybe have one gender for impl requirements and the other for author requirements? |
| 06:11 | <Von_Davidicus> | Sadly, I can't see what those characters are. Alas. |
| 06:13 | <Von_Davidicus> | Well, tomorrow we'll see if my teacher consigns me to the Funny Farm. Or if he merely blows his stack. |
| 06:44 | <zcorpan> | ok here's the "enter" function to be used in the tree walker at the bottom of http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html to give requirements hats: function(node) { |
| 06:44 | <zcorpan> | if (node instanceof Text) { |
| 06:44 | <zcorpan> | node.data = node.data.replace(/\b(must\s+not|must|may|should\s+not|should)\b/g, function(match) { return match + '\uD83C\uDFA9'; }); |
| 06:44 | <zcorpan> | } |
| 06:44 | <zcorpan> | } |
| 06:45 | <heycam> | zcorpan, you are either up too early or too late |
| 06:45 | <zcorpan> | i had set my clock at 06:00 |
| 06:54 | <jgraham> | That isn't even a real time |
| 06:55 | <zcorpan> | of course it is |
| 06:56 | <zcorpan> | i can't decide if i should send feedback to www-style about url() not caring about non-ascii or if i should wait for the URL spec |
| 06:58 | <matjas> | lol @ http://twitter.com/panic/status/204826332322992128 |
| 06:59 | <heycam> | zcorpan, I already sent a mail |
| 06:59 | <zcorpan> | ah |
| 07:00 | <annevk> | matjas: :/ |
| 07:00 | <zcorpan> | ok, that's it. duck duck go just isn't good enough. it doesn't find me what i'm looking for. back to google. :-( |
| 07:00 | <Von_Davidicus> | matjas? |
| 07:01 | <matjas> | Von_Davidicus: “Yeah, a good suggestion to remove that tumor. Make sure to report that after we stitch.” |
| 07:02 | <annevk> | heycam: yes you can |
| 07:02 | <annevk> | heycam: in addition their URL character encoding is always utf-8, contrary to HTML |
| 07:02 | <annevk> | heycam: not that URL character encoding is a particularly well documented concept... |
| 07:02 | <heycam> | annevk, ok cool, but I couldn't find where it says how to interpret the characteres within the url( ) |
| 07:03 | <annevk> | heycam: probably not well defined; but they're parsed just like in HTML |
| 07:03 | <annevk> | heycam: unless parsing of url() fails of course |
| 07:03 | <annevk> | that is, spaces and such work fine |
| 07:04 | <heycam> | annevk, interpret as in "this sequence of characters in the URI token is a (new-style) URL, or a URI, or a URL" |
| 07:04 | <heycam> | I guess CSS will refer to the new URL spec at some point |
| 07:04 | <annevk> | but you might need to escape the space to make CSS parsing not trip; forgot about that |
| 07:04 | <annevk> | yeah |
| 07:04 | <annevk> | CSS and XHR are the same |
| 07:04 | <heycam> | in that case, $svgspec =~ s/funciri/url/g :D |
| 07:05 | <annevk> | HTML also sets the URL encoding to something weird |
| 07:05 | <zcorpan> | or use url("....") |
| 07:05 | <Von_Davidicus> | What does XHR stand for? |
| 07:05 | <annevk> | heycam: yeah |
| 07:05 | <annevk> | heycam: SVG should do the same as HTML I think, but probably minus the crazy encoding stuff, although given a mixed document... |
| 07:05 | <annevk> | Von_Davidicus: XMLHttpRequest |
| 07:06 | <heycam> | annevk, I haven't looked into what crazy encoding stuff there is in HTML (for interpreting href attributes differently from the documenting encoding or something I guess?) |
| 07:06 | <zcorpan> | annevk: i guess teh URL spec will deal with unpaired surrogates, yeah? |
| 07:06 | <Von_Davidicus> | Okay. Hmm--curiosity question: what, aside from AJAX, uses XMLHttpRequest? |
| 07:07 | <annevk> | heycam: for interpreting them using the document encoding actually |
| 07:07 | <heycam> | oh |
| 07:07 | <annevk> | heycam: cause URLs normally use utf-8 |
| 07:07 | <heycam> | ahh |
| 07:07 | <heycam> | I see |
| 07:07 | <heycam> | so interpreting %nn things differently |
| 07:07 | <zcorpan> | no |
| 07:07 | <zcorpan> | interpreting raw characters differently |
| 07:07 | <heycam> | oh |
| 07:08 | <heycam> | but that's sensible isn't it? interpreting the raw characters according to the document encoding? :) |
| 07:08 | <annevk> | heycam: è becomes two %hh normally, but one %hh for e.g. windows-1252 |
| 07:08 | <zcorpan> | see /topic |
| 07:08 | <heycam> | sensible = illogical for the web platform :) |
| 07:08 | <annevk> | heycam: and only when part of the query string of course |
| 07:08 | <annevk> | heycam: in the path it's always two %hh |
| 07:09 | <annevk> | heycam: see http://annevankesteren.nl/presentations/1F4A9.html |
| 07:09 | <zcorpan> | heycam: it's not really sensible if the url goes to a different server, for instance |
| 07:09 | <heycam> | ok. well I'm going to forget about those details for the moment and hopefully I'll just add some references to toher specs and things will just work! |
| 07:09 | <annevk> | "just work" mwaha |
| 07:10 | <annevk> | zcorpan: haven't played with isolated surrogates; I was kind of hoping someone else would be doing URL stuff, but I guess arv just wanted to update a few small things |
| 07:11 | <zcorpan> | i guess we should just use the webidl code-units-to-utf-8 rules when the input is code units |
| 07:12 | <zcorpan> | (although we can't use that for the query if url encoding isn't utf-8, of course) |
| 07:12 | <heycam> | I don't think I added those rules, just code units to characters |
| 07:12 | <zcorpan> | ah. still |
| 07:13 | <annevk> | we could use those for the query too I think |
| 07:14 | <zcorpan> | yeah |
| 08:04 | <jgraham> | Turns out that having three copies of the complete spec open makes restarting your browser slow |
| 08:45 | <Stevef> | proposal to add <transcript> element to HTML5 http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement |
| 10:27 | <matjas> | annevk: *now* i understand what you liked about my twitter bio |
| 10:28 | <annevk> | took you long enough :p |
| 10:28 | <matjas> | none of you guys told me about that presentation :'( |
| 10:28 | <annevk> | matijs recorded it for you I thought |
| 10:29 | <annevk> | but he prolly never got around to do the work of syncing the various media together |
| 10:29 | <annevk> | it sounded kind of ambitious when he pitched it in the train |
| 10:39 | <matjas> | annevk: huh, i thought that was the big5 presentation |
| 10:40 | <odinho> | annevk: My setup is better then, because it needs no postproduction. Live-switching, cutting and streaming everything while the presentation is going :-) |
| 10:42 | <annevk> | matjas: never presented on big5 in detail |
| 10:42 | <annevk> | matjas: think that would've gone too far :) |
| 10:42 | <matjas> | well, fingers crossed for #fronteers12 |
| 10:42 | <annevk> | Ms2ger`: yo yo |
| 10:42 | <annevk> | Ms2ger`: yo yo yo |
| 10:43 | <Ms2ger`> | Hi |
| 10:43 | <annevk> | Ms2ger`: yay it worked |
| 10:43 | <annevk> | Ms2ger`: so Anolis "NOTE" picks the wrong style sheet |
| 10:43 | <Ms2ger`> | I blame gsnedders |
| 10:43 | <annevk> | Ms2ger`: not sure if we should bother fixing it |
| 10:43 | <annevk> | it uses W3C Note while everything else says W3C Working Group Note |
| 10:43 | <annevk> | (the latter I want) |
| 10:44 | <annevk> | not really fond of this whole Note thing though |
| 10:44 | <annevk> | but I'm happy doing Art another favor |
| 10:44 | <Ms2ger`> | What says "W3C Note"? |
| 10:45 | <Ms2ger`> | Oh, huh |
| 10:45 | <annevk> | there's W3C-Note and W3C-WG-Note |
| 10:45 | <annevk> | prolly also W3C-IG-Note and various others |
| 10:45 | <annevk> | it's kind of silly Notes are not just a global thing |
| 10:46 | <annevk> | because they all mean nothing |
| 10:46 | <annevk> | but I guess W3C likes it complicated |
| 10:46 | <annevk> | keeps people busy |
| 10:46 | <zcorpan> | W3C-CG-Note? |
| 10:47 | Ms2ger` | doesn't understand this code |
| 10:55 | <matijsb> | annevk: still not got round to it :| |
| 10:57 | <gsnedders> | Ms2ger`: For once blaming me seems to be legit. |
| 10:57 | <gsnedders> | :) |
| 12:18 | <annevk> | Velmont: yo yo |
| 12:18 | <annevk> | Velmont: do you remember what came out of the webapps discussion? |
| 12:18 | <annevk> | Velmont: regarding CORS |
| 12:18 | <annevk> | I guess I have some time to work on that now... |
| 12:21 | annevk | finds http://lists.w3.org/Archives/Public/www-archive/2012May/att-0022/minutes-2012-05-02.html#item03 |
| 12:23 | <annevk> | okay so that was a comment from the minute taker |
| 12:24 | <annevk> | but instead of working on the technical feedback, he worked on the minutes :p |
| 12:26 | <annevk> | is there an easy way to convert a bunch of HTML to wiki? |
| 12:27 | <Ms2ger`> | Something like http://openfacts2.berlios.de/html2wiki/index.php ? |
| 12:56 | <jgraham> | Hmm, var t0=Date.now(); document.write("<link rel='stylesheet' src='slowloading.css'><script>alert(Date.now() - t0)<\/script>"); |
| 12:57 | <jgraham> | Should that document.written script block on the stylesheet loading? |
| 12:58 | <jgraham> | (afaict browsers don't block, but I can't quite work out why the spec wouldn't block there) |
| 13:02 | <smaug____> | hsivonen: ^ |
| 13:33 | <webben> | hsivonen: What's the holdup on getting latest nu.validator.htmlparser into maven? is that done by a third party? |
| 13:52 | gsnedders | gets rid of 10/13 failures in html5lib on Py2 |
| 13:52 | <gsnedders> | (Mainly because I can) |
| 14:01 | <gsnedders> | jgraham: Do you have any idea what the expected behaviour of FormFiller is? |
| 14:03 | <jgraham> | gsnedders: No |
| 14:04 | <gsnedders> | jgraham: Greast. |
| 14:04 | <gsnedders> | *Great |
| 14:04 | gsnedders | is tempted to drop it and see who complains |
| 14:04 | <gsnedders> | html5lib contains too much shit. |
| 14:06 | <jgraham> | gsnedders: I am totally happy for you to do that |
| 14:10 | <gsnedders> | It's breaking in some fairly subtle way under Py3 |
| 14:12 | <gsnedders> | It impls something that has been removed from the spec |
| 14:20 | <jgraham> | Kill it. It's in vc if people want to revive it |
| 14:22 | <annevk> | Ms2ger`: looks interesting |
| 14:23 | <gsnedders> | jgraham: Have killed. Also fixed all but three of the current failures under Py2. |
| 14:24 | <gsnedders> | jgraham: (7 errors, 4 failures under Py3) |
| 14:29 | <jgraham> | Presumably you don't have lxml installed? |
| 14:30 | <jgraham> | I think we should kill the beautifulsoup support also, since BS3 used html5lib as the backend (I think) |
| 14:30 | <gsnedders> | No, I don't. |
| 14:31 | <jgraham> | Dunno what BS4 does |
| 14:31 | <jgraham> | Oh, BS4 can use html5lib |
| 14:32 | <jgraham> | (I assume it doesn't depend on our BS support) |
| 14:35 | <gsnedders> | Hmm, somewhat surprising that Python doesn't fast-case encoding a Unicode string to its underlying repr |
| 14:37 | <gsnedders> | The encoding is special-cased, but not decoding. |
| 14:39 | <gsnedders> | Also: html5lib/constants.py takes a while to run 2to3 on. |
| 15:14 | <annevk> | Ms2ger`: that converter fails horribly :( |
| 15:14 | <Ms2ger`> | Google had more :) |
| 15:15 | <annevk> | found a better one indeed |
| 15:16 | <jgraham> | http://johnmacfarlane.net/pandoc/ ? |
| 15:17 | <annevk> | http://labs.seapine.com/htmltowiki.cgi |
| 15:27 | <annevk> | http://www.w3.org/wiki/CORS |
| 15:32 | <mhausenblas> | in case you haven't seen it yet annevk … http://apiblog.youtube.com/2012/05/unlocking-javascripts-potential-with.html |
| 15:32 | <annevk> | mhausenblas: hadn't seen that yet, sweet |
| 15:33 | <mhausenblas> | yup ;) |
| 15:36 | <annevk> | ojan_away: hey |
| 15:36 | <annevk> | ojan_away: yt? |
| 15:36 | <annevk> | ojan_away: if you guys are not planning on implementing stacked fullscreen I think it would be good to mention that somewhere |
| 15:36 | <annevk> | ojan_away: hober told me Apple was not to keen on that either so maybe it should be removed |
| 15:37 | <annevk> | ojan_away: having said that, you still need the stack on the "top layer" of course for <dialog> |
| 15:40 | jgraham | wonders which part of _away was unclear ;) |
| 15:41 | <annevk> | jgraham: the part that said "has joined" |
| 15:42 | <annevk> | I wonder how often Julian is going to repeat his point... |
| 15:48 | <annevk> | how is <script crossorigin> tracked? |
| 15:48 | <annevk> | is there a bug on HTML or an unclosed email discussion? |
| 15:53 | <zewt> | clearly what we need is: more threads |
| 15:53 | <zewt> | that would solve everything! |
| 15:53 | <zewt> | mailing list NIH |
| 15:54 | <dglazkov> | good morning, Whatwg! |
| 15:59 | <Ms2ger`> | Good, dgathright |
| 15:59 | <Ms2ger`> | And dglazkov |
| 16:00 | <dglazkov> | :) |
| 16:14 | <Workshiva> | I guess there's nothing even close to a spec for XMLSerializer? |
| 16:16 | <Ms2ger`> | Sure is |
| 16:16 | <Ms2ger`> | Workshiva, http://html5.org/specs/dom-parsing.html |
| 16:16 | <Ms2ger`> | Not terribly close, but it's something |
| 16:17 | <Workshiva> | Looks buggy too |
| 16:18 | <Ms2ger`> | Sure |
| 16:18 | <Workshiva> | Do you want my bug repor there? :) |
| 16:19 | <Ms2ger`> | If zcorpan hasn't filed it yet :) |
| 16:20 | <Workshiva> | There's no escaping of text nodes in the non-cdata case |
| 16:21 | <Workshiva> | Opera 11.5 serializes <> as <> and I was looking for something to confirm that's not right |
| 16:22 | <Workshiva> | (Chrome gives <> as expected) |
| 16:22 | <niftylettuce> | does anyone know of a possible way to have a setter in FileList API? |
| 16:22 | <Ms2ger`> | <> sounds good |
| 16:22 | <Ms2ger`> | In HTML, at least... |
| 16:23 | <Ms2ger`> | Is XML sillier? |
| 16:23 | <Workshiva> | I'm sure it works, but it's inconsistent and silly |
| 16:24 | <espadrine> | Does anyone have an idea for a better scrollIntoViewIfNeeded design to implement in CSSOM? |
| 16:34 | <gsnedders> | jgraham: I'm struggling to see how to handle Unicode files under Python 3 while preserving lone surrogates as we do under Py2. |
| 16:36 | <gsnedders> | jgraham: Most Python codecs disallow lone surrogates, so encode/decode doesn't work (the fact that the UTF-8 one allows them is different to UTF-16 under Py2, for example). |
| 16:39 | <gsnedders> | Sorry, Unicode strings. |
| 16:40 | <gsnedders> | Unicode files are #221 |
| 16:42 | <gsnedders> | s/221/202/ |
| 16:46 | <zewt> | gsnedders: more or less they're logically equivalent to invalid UTF-8 sequences, an encoding error that you typically can't round-trip through any other encoding |
| 16:47 | <zewt> | technically you *can* (unlike most invalid sequences) with other unicode encodings, but whether that's a good idea is another question |
| 16:47 | <gsnedders> | zewt: Yes, I know. |
| 16:47 | <zewt> | i know you know :) |
| 16:47 | <gsnedders> | But at the moment html5lib expects them to round-trip. |
| 16:49 | gsnedders | thinks detectEncoding is broken under Python 3 and should be asserting, but isn't in any tests |
| 16:49 | gsnedders | wonders if we have tests for that |
| 16:52 | <gsnedders> | zewt: The HTML spec defines behaviour for all Unicode characters, not just valid ones. |
| 16:52 | <jwalden> | "the whatwg site actually uses the offline manifest, so after the first load you should be able to open that same page without internet access" USEFUL THING I DID NOT KNOW \o/ |
| 16:52 | jwalden | highlights those lines on http://krijnhoetmer.nl/irc-logs/whatwg/20120522 |
| 16:53 | gsnedders | thinks someone is a bit too happy |
| 16:54 | <jwalden> | :-P |
| 16:54 | <jwalden> | plz to not be disturbing my happiness |
| 16:54 | gsnedders | mumbles something about the [[Prototype]] setter |
| 16:54 | gsnedders | hides |
| 16:55 | <jwalden> | YOU'D BETTER HIDE |
| 16:55 | <jwalden> | :-D |
| 16:56 | <Ms2ger`> | jwalden, Java |
| 16:56 | Ms2ger` | hides too |
| 16:56 | gsnedders | needs to sit down and work out what to do about the whole accessor v. weird magic argument |
| 16:56 | <gsnedders> | (for __proto__) |
| 17:00 | <gsnedders> | (I'd rather have it as an accessor even if we posion the property descriptor) |
| 17:01 | <zewt> | gsnedders: where does it require being able to round-trip stray surrogates? in the parser, at least, they should parse straight to FFFD |
| 17:03 | <gsnedders> | zewt: What makes them do that? |
| 17:03 | <zewt> | browsers don't agree on it, but that's Firefox's behavior, and it's the only thing that makes sense |
| 17:04 | <Ms2ger`> | Thanks ;) |
| 17:04 | <gsnedders> | zewt: That's not what the spec says |
| 17:04 | <zewt> | then, at least on first impression, the spec is wrong |
| 17:04 | <zewt> | (last I recall, it *is* what the encoding spec says, FWIW) |
| 17:05 | <gsnedders> | Well, it does for the UTF-8 case. |
| 17:05 | <gsnedders> | For every other case it is unclear. |
| 17:05 | <zewt> | that's what the encoding spec is trying to fix, i believe :) |
| 17:07 | <zewt> | also FWIW, firefox and opera parse it to fffd, ie and webkit just spit out the surrogate |
| 17:07 | <zewt> | (ie8; would have to fire up a VM for ie9) |
| 17:08 | <gsnedders> | \xD8\x00 is the UTF-16BE U+D800, right? |
| 17:08 | gsnedders | checks he isn't being stupid with endianness |
| 17:09 | <zewt> | yeah |
| 17:10 | <zewt> | http://zewt.org/~glenn/surrogate%20test.html.utf16 |
| 17:10 | <zewt> | editing utf-16 files with a broken surrogate in vim is annoying, because vim goes "oh, I guess this isn't utf-16" and falls back on latin1 |
| 17:11 | <zewt> | and i can never remember how to force reloading in vim with a specific encoding |
| 17:14 | <gsnedders> | Well, it isn't UTF-16. |
| 17:14 | <zewt> | sure it is; it's just UTF-16 with an error |
| 17:14 | <gsnedders> | Well, sure, but it's equally UTF-8 with an error. :) |
| 17:14 | <zewt> | vim just guesses wrong, since it's a heuristic |
| 17:15 | <zewt> | the fact that almost every other byte is \x00 points more strongly to utf-16 with an error :) |
| 17:16 | <grigs> | so… um… about responsive images… |
| 17:16 | grigs | ducks |
| 17:17 | Ms2ger` | re-aims and shoots |
| 17:17 | <grigs> | lol |
| 17:17 | <Ms2ger`> | Go join a CG ;) |
| 17:17 | <grigs> | LOL. very nice. |
| 17:18 | <grigs> | Ok, seriously, I have doubts about our ability to reconcile lookahead pre-parser behavior and responsive images as authors want to use them. |
| 17:19 | <grigs> | I wrote a lot about it last night: http://blog.cloudfour.com/the-real-conflict-behind-picture-and-srcset/ |
| 17:19 | <zewt> | can you write less about it for those of us with day jobs :) |
| 17:19 | <grigs> | :-) |
| 17:20 | <grigs> | The gist is the pre-parser wants to know what image exists before layout is calculated, but responsive images don’t want to have that defined until layout is calculated. |
| 17:20 | <jgraham> | I only read the conclusion |
| 17:20 | <jgraham> | But I assumed that the issue was what you just said |
| 17:20 | <jgraham> | This is why we only use the viewport size |
| 17:21 | <grigs> | Yep, but using the viewport size causes a bunch of problems. |
| 17:21 | <jgraham> | And assume the layout is such that a specific viewport width/height would correspond to a specific container width/height |
| 17:21 | <jgraham> | Well it *solves* a bunch of problems |
| 17:21 | <zewt> | ("as authors want to use them"--some authors, not me) |
| 17:21 | <gsnedders> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17151 |
| 17:22 | <jgraham> | e.g. makes the technique possible to implement in a non-sucky way |
| 17:22 | <jgraham> | If authors really can't cope with the viewport proxy and are willing to kill pageload perf to get something different it will be obvious when they implement something different in javascript |
| 17:23 | <jgraham> | In the meantime assuming the proxy is good enough is the only viable solution |
| 17:23 | <gsnedders> | jgraham: '\ud800a' should produce a parse error according to what? |
| 17:23 | <gsnedders> | hsivonen: ^^ |
| 17:25 | <grigs> | jgraham: i like the phrase 'viewport proxy'. that's a helpful way to describe it. |
| 17:27 | <grigs> | jgraham: the question you pose about coping with the viewport proxy is a good one. as it stands right now, i don't know whether I would choose to implement srcset or not. |
| 17:27 | <grigs> | actually, i know i would choose to implement pixel density srcset, but not sure about the viewport proxy. |
| 17:29 | <jgraham> | grigs: Does it seem worse than the alternative (no feature)? |
| 17:29 | <grigs> | jgraham: i'm honestly torn about that. |
| 17:30 | <zewt> | gsnedders: http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#legacy-utf-16-encodings |
| 17:30 | <grigs> | it's something i've been noodling on a lot in the last week. |
| 17:31 | <jgraham> | I don't see how mot having the feature would be better, really |
| 17:31 | <jgraham> | *not |
| 17:31 | <grigs> | arguments against the feature: |
| 17:32 | <zewt> | that was a short list |
| 17:32 | <grigs> | * It encodes breakpoints into the HTML making markup harder to maintain. |
| 17:32 | <grigs> | * Because it is a proxy, it can be difficult to match the breakpoints defined in CSS. |
| 17:32 | <zewt> | all it does is encode image dimensions into the HTML (and resources), which is nothing new |
| 17:33 | <grigs> | zewt: No, it encodes image dimensions and design decisions (viewport breakpoints) into the markup which is new. |
| 17:34 | <jgraham> | (I really wish "breakpoints" hadn't been co-opted to mean something different from existing use in the context of debugging) |
| 17:34 | <zewt> | image dimensions in markup is not new. <img width=16 height=16> |
| 17:34 | <grigs> | zewt: the dimensions in srcset are viewport dimensions, not image dimensions. |
| 17:35 | <zewt> | the results of the calculation are image dimensions. |
| 17:35 | <jgraham> | grigs: I'm not sure it is a design decision. It is selecting different *content* |
| 17:35 | <jgraham> | So in that sense it should be in the content layer (i.e. HTML) |
| 17:35 | <zewt> | only the *input* is viewport dims |
| 17:35 | <grigs> | jgraham: as an author, how do you pick when to switch from one resolution image to another? |
| 17:36 | <zewt> | jgraham: well, that's true for pixel density, less so if you're selecting images of different sizes |
| 17:36 | <jgraham> | zewt: Images of different sizes are more different than images of different pixel density |
| 17:36 | <zewt> | actually, one thing that's really strange: there's no way in the markup to say what the pixel dimensions of each candidate are (equivalent to @width/@height for @src), which seems sort of bad |
| 17:37 | <zewt> | jgraham: that's what i said |
| 17:37 | <gsnedders> | jgraham: We need more tests :( |
| 17:37 | <zewt> | eg. if you're showing a 1000x100 image for viewports up to 1024x768 and a 2000x100 image for viewports higher than that |
| 17:38 | <jgraham> | grigs: I feel like there is some non-obvious answer to that I am supposed to give (i.e. not "pick some pixel widths to use as my breakpoints). Maybe that isn't really what people do :) |
| 17:38 | <jgraham> | gsnedders: That doesn't seem surprising |
| 17:38 | <grigs> | put differently, how do you decide at which viewport dimensions you should change from a.jpg to b.jpg? there is nothing about the image itself that would tell you that it makes sense to switch at 500px vs. 700px vs. X. |
| 17:40 | <grigs> | So what is most likely to happen is that authors will match the srcset dimensions to their media query “breakpoints” which is why I say design decisions will be in srcset. |
| 17:40 | <jgraham> | grigs: Well clearly in the normal case you would make a design decision that your layout should switch at some width. But the srcset feature would be useful even without CSS |
| 17:40 | <gsnedders> | jgraham: Do we have *any* tests for encoding detection? |
| 17:40 | <jgraham> | gsnedders: Ask sam :p |
| 17:40 | <jgraham> | Or maybe mark |
| 17:40 | <jgraham> | (glwt btw :p) |
| 17:40 | <grigs> | jgraham: agreed that it is useful w/o css. |
| 17:41 | <jgraham> | grigs: If yur point is that you have to sync the markup and the style, I agree, but that's already true to some extent |
| 17:41 | <gsnedders> | jgraham: Mark is especially hard :P |
| 17:41 | <jgraham> | gsnedders: My point exactly :) |
| 17:43 | grigs | continues arguments against the feature |
| 17:43 | <grigs> | * No support for ems which is where authors appear to be headed with media queries |
| 17:44 | <grigs> | * Seems possible/likely a better long term solution would be a different image format so we're picking a short term solution and it will become canon. |
| 17:45 | <jgraham> | grigs: You can argue it's evil but practically converting pixels->ems as a constant is good for the vast majority of users |
| 17:45 | <jgraham> | (for the rest using full page zoom might be better than increased default font size) |
| 17:46 | <grigs> | jgraham: i doubt i would argue anything in web tech is evil. ;-) |
| 17:46 | <jgraham> | I don't see how a different image format can possibly work |
| 17:47 | <jgraham> | I mean I see how it could solve the pixel density case. But I don't see how it could solve the "different assets at different sizes, only downloading those that are actually used" case |
| 17:48 | <grigs> | jgraham: i think the different assets at different sizes, what I've called art direction, may be complicating things too much. |
| 17:51 | <jgraham> | It seems hard to just ignore one of the major use cases that people have put forward |
| 17:51 | <grigs> | jgraham: I know. I was one of the people pushing it. :-) |
| 17:52 | <grigs> | i'm arguing a 180 from where I was a week and a half ago. but i'm not wedded to an outcome. just trying to make sure we get a good solution. |
| 17:54 | <annevk> | grigs: would the breakpoints not be set at viewport widths of common devices? |
| 17:55 | <grigs> | annevk: no, web designers are moving away from that quickly. |
| 17:55 | <grigs> | annevk: for one, there are no common widths http://stephanierieger.com/the-trouble-with-android/ |
| 17:57 | <grigs> | annevk: second, it makes more sense to pick breakpoints based on where the content or the design starts looking bad. basically resize the browser until the page looks like crap, write down the resolution, create a breakpoint to fix it, then resize again. |
| 18:06 | <annevk> | grigs: yeah mkay, so your proposal is to not have this at all? |
| 18:06 | <grigs> | annevk: i'm not proposing anything yet. i'm testing ideas. |
| 18:07 | <tantek> | a reasonable approach |
| 18:10 | <annevk> | I guess one could argue the alternative representations are presentational |
| 18:10 | <gsnedders> | Ran 25261 tests in 42.323s: FAILED (failures=3) |
| 18:11 | <annevk> | in which case you'd do e.g. img { content:url(smaller) } |
| 18:11 | <gsnedders> | Ran 25261 tests in 40.888s: FAILED (failures=3) |
| 18:11 | <Ms2ger`> | You FAIL |
| 18:11 | <gsnedders> | I'm calling that success! |
| 18:11 | <annevk> | thereby keeping the media queries and such in CSS too |
| 18:11 | <MattWilcox> | Just popping in - I'm with Grigs on this |
| 18:12 | <MattWilcox> | I can't see how responsive images can ever work alongside the pre-parser |
| 18:12 | <annevk> | though 'content' doesn't support the 2x stuff |
| 18:12 | <MattWilcox> | The two ideas are mutually exclusive. |
| 18:13 | <grigs> | I would state it a little differently than MattWilcox did. I hope there is a way they can work alongside each other, but am beginning to fear they can't. |
| 18:13 | <MattWilcox> | I'd love them to work alongside each other - i just don't think it's possible - I've been thinking about this for a few weeks and they just don't gel |
| 18:13 | <MattWilcox> | RespImgs would have been a simple hack to fix with nothing but JS if it wasn't for the pre-parser |
| 18:14 | <MattWilcox> | Admittedly, still a hack, but it'd have worked. Indeed *did* work for the Boston Globe - right up until pre-parsing got turned on |
| 18:14 | <MattWilcox> | Which is why I've almost come full circle and think it's back to sending headers along with requests so the server can do the adaption. |
| 18:15 | <MattWilcox> | Adaptive Images *just works* but it has to hack by using cookies instead of headers |
| 18:15 | <MattWilcox> | Anyway, I have to go - hopefully speak to you all soon. |
| 18:15 | <grigs> | lol |
| 18:15 | <annevk> | server doesn't work for CDN |
| 18:16 | <MattWilcox> | PS I mean http://adaptive-images.com specifically not the general concept |
| 18:16 | <MattWilcox> | Server can work for a CDN when it's headers |
| 18:16 | <MattWilcox> | CDNs are smart these days, not just dumb |
| 18:16 | <MattWilcox> | Anyway, have to go! |
| 18:16 | <MattWilcox> | :) |
| 18:16 | <annevk> | "smart" |
| 18:16 | <annevk> | CORS was already hard |
| 18:17 | <annevk> | asking them to do content negotiation... |
| 18:17 | <annevk> | which as a concept failed pretty badly on the web thus far |
| 18:17 | <annevk> | ... |
| 18:17 | <grigs> | annevk: to your question about alternative representations being presentational, i think the art direction use case is closest to presentational. sometimes the image changes orientation and text should reflow as well at a breakpoint |
| 18:17 | <hober> | annevk: yeah. Someone has a problem and says "I'll use conneg." Now they have N problems. |
| 18:18 | <annevk> | grigs: yeah, you could have your canonical content in markup and the adaptations in CSS |
| 18:18 | <grigs> | annevk: the nice thing about hober's original proposal was it only dealt with pixel density and thus avoided this problem. smart guy. ;-) |
| 18:19 | <annevk> | grigs: also keeps the media queries nicely isolated and for a single purpose |
| 18:20 | <gsnedders> | jgraham: So yeah, we have no tests for the meta pre-parser |
| 18:21 | <annevk> | the problem is of course that if you do that you download too much resources |
| 18:21 | <grigs> | one idea i had based on the current srcset syntax would be to try to teach people not to match the dimensions in srcset with their media queries. Instead to teach people to use some sort of “common” tiers of images that have nothing to do with design decisions. |
| 18:21 | <annevk> | so you'd prolly not use <img> at all |
| 18:21 | <annevk> | and just play with <div> and 'background'/'content' |
| 18:21 | <gsnedders> | jgraham: Fairly certain it's broken under Py3. |
| 18:21 | <jgraham> | gsnedders: That sounds like my fault :\ |
| 18:22 | <annevk> | I think people do that already as animating <img> is more expensive than <div> + background... |
| 18:24 | <grigs> | i'm not sure what the “common” ones would be or how to convince people to implement srcset that way, but it would mean that the different versions of the image were only there to give the browser options, not because of design decisions. |
| 18:26 | <annevk> | grigs: I don't really follow that idea |
| 18:27 | <grigs> | annevk: let me try again. right now when I see the dimensions listed in the srcset syntax, i automatically translate that into media query syntax and try to figure out how to match what is defined in srcset with what is defined in css. |
| 18:27 | <grigs> | annevk: i suspect that many designers have done the same (see Jeremy Keith's points on the list) and will do so in the future. |
| 18:28 | <annevk> | gotta eat brb |
| 18:29 | <grigs> | annevk: matching srcset dimensions to media query breakpoints is only necessary in the art direction use case. if we're simply dealing with the same image available at different sizes, then it would behoove the document author to avoid tying the different sizes of the image (the content) to the presentation (media query breakpoints). |
| 18:31 | gsnedders | snarls at people manually editing html5lib py3 |
| 18:31 | Ms2ger` | snarls back |
| 18:32 | <gsnedders> | jgraham: We seem to have both fixed the nose noise. |
| 18:32 | <gsnedders> | bah! |
| 18:32 | <grigs> | annevk: so instead, if authors simply picked three sizes of the image and defined three random viewport dimensions in which they should be used per the srcset syntax, then when a redesign comes along, the srcset code likely won't need to change. the srcset code wouldn't be tied to the design (as expressed in media query breakpoints) |
| 18:35 | <WeirdAl> | dglazkov: ping |
| 18:35 | <dglazkov> | WeirdAl: pong |
| 18:36 | <WeirdAl> | I sat with rniwa this weekend, and he suggested I talk with you about your HTML template spec... it's very interesting and parallels one of my own ideas |
| 18:37 | <rniwa> | dglazkov: yeah sorry i was going to tell you today in person (i'm in mtv today) |
| 18:37 | <dglazkov> | I didn't know rniwa knew Weird Al Yankovic! |
| 18:37 | <rniwa> | dglazkov: basically WeirdAl is creating an XML editor |
| 18:37 | <WeirdAl> | 8-) |
| 18:37 | <dglazkov> | can you write a song about me? |
| 18:37 | <rniwa> | dglazkov: that lets you edit templates |
| 18:37 | <WeirdAl> | <== Alex Vincent |
| 18:37 | <rniwa> | dglazkov: and use that as sort of building builds to build XML documents |
| 18:37 | <dglazkov> | From Child's Play?! That's even better! |
| 18:38 | <WeirdAl> | arrrgh |
| 18:38 | <dglazkov> | :) |
| 18:38 | <rniwa> | dglazkov: so and he uses things like <repeat> from XBL |
| 18:38 | <rniwa> | dglazkov: to accomplish this |
| 18:39 | <WeirdAl> | uh, I don't think XBL has a repeat element, unless I'm out of date (which wouldn't surprise me) |
| 18:39 | <grigs> | Wait… so WeirdAl is Alex Vincent the child actor? |
| 18:39 | <WeirdAl> | no, I am not |
| 18:39 | <rniwa> | dglazkov: it appeared that a lot of things he invented for his xml editor were very closedy related to the component model & templating |
| 18:39 | <dglazkov> | rniwa: neat! |
| 18:40 | <WeirdAl> | dglazkov: except that I have only gotten bits and pieces to work over the years, and I'm writing a fresh DOM impl in JS to nail that once and for all :p |
| 18:40 | <grigs> | WeirdAl: sorry. couldn't resist. :-) |
| 18:40 | WeirdAl | is a bit nuts |
| 18:40 | <dglazkov> | WeirdAl: you're finally home then. |
| 18:40 | <dglazkov> | welcome to #whatwg |
| 18:41 | <WeirdAl> | hehe, I've been hanging out here for a while... my repeat element's inspired by an early HTML5 draft that had repetition blocks |
| 18:41 | <dglazkov> | WeirdAl: any code I can look at? |
| 18:41 | WeirdAl | thinks |
| 18:42 | <WeirdAl> | I've got code on my sourceforge repo, but it's extremely old |
| 18:42 | <WeirdAl> | I'm not even sure if I have a working demo anymore |
| 18:42 | <dglazkov> | I am sorry, I can't fund your venture without a working demo |
| 18:42 | dglazkov | pretends to be rich |
| 18:42 | WeirdAl | chuckles |
| 18:43 | <WeirdAl> | basically, my repeat element does start out a lot like your template element, but with the added benefit of a for loop |
| 18:44 | <dglazkov> | WeirdAl, this sounds like MDV. Are you familiar with that? |
| 18:44 | <dglazkov> | http://code.google.com/p/mdv/ |
| 18:44 | <WeirdAl> | I took a glance at it on Saturday afternoon, but it was a lot to absorb at once |
| 18:44 | <dglazkov> | rafaelw_ is the spiritual leader there. |
| 18:44 | <gsnedders> | jgraham: Py3 stuff pushed |
| 18:45 | <dglazkov> | WeirdAl: where are you based? We can chat over lunch if you'd like |
| 18:45 | <WeirdAl> | I'm in the SF Bay Area |
| 18:45 | <WeirdAl> | and as I told rniwa, I'd like that very much |
| 18:46 | <dglazkov> | what a coincidence! are you in any particular part of the bay area? |
| 18:46 | dglazkov | is in Mountain View |
| 18:46 | <WeirdAl> | I live in San Leandro and work in Oakland |
| 18:46 | <WeirdAl> | but no car - public transit's my friend |
| 18:47 | <dglazkov> | whoa. Carless people. What will they think of next? |
| 18:48 | <Ms2ger`> | AI's wishing you a good morning? |
| 18:48 | <WeirdAl> | carless engineers? :) |
| 18:48 | <tgecho> | peopleless cars |
| 18:48 | <dglazkov> | I'd feel kind of bad asking you to find your way down to Mountain View, but the drive to Oakland seems also a bit daunting |
| 18:49 | <dglazkov> | ooh |
| 18:49 | <WeirdAl> | dglazkov: I have some extremely poorly documented code at http://sourceforge.net/p/verbosio/code/ci/c0049422968454a8e6869b4cb24317eccd756473/tree/experimental/floor13/chrome/res/modules/MarkupRepeatBindings.jsm?force=True |
| 18:49 | <dglazkov> | G+ Hangouts an option? :) |
| 18:49 | WeirdAl | is a heathen, he doesn't use Google+ |
| 18:49 | <dglazkov> | I thought only heathens were on G+ |
| 18:49 | <WeirdAl> | but SF is easy for both of us to get to |
| 18:50 | <dglazkov> | I can never remember |
| 18:50 | <Ms2ger`> | I would, but the Empire doesn't let me :( |
| 18:50 | <dglazkov> | sure. I should be in SF at least one day next week. |
| 18:50 | <WeirdAl> | well, Monday is Memorial Day |
| 18:51 | <dglazkov> | so, not Monday :) |
| 18:51 | <WeirdAl> | :p the only other options really are weekends |
| 18:51 | <WeirdAl> | since this project is *not* part of my day job |
| 18:52 | <dglazkov> | ah. my weekends and holidays have been donated to The Family. |
| 18:52 | <WeirdAl> | at least you have one. |
| 18:52 | <dglazkov> | that didn't come out right |
| 18:52 | <dglazkov> | :) |
| 18:53 | <WeirdAl> | no, I think that came out exactly right. Family comes first. |
| 18:53 | <dglazkov> | WeirdAl: one thing to consider: rafaelw_ is in SF. Maybe you should catch him over lunch? |
| 18:54 | <dglazkov> | WeirdAl: he is just like me, except less annoying. |
| 18:54 | <WeirdAl> | hmm |
| 18:56 | <WeirdAl> | ... I guess part of the reason I hesitate is that frankly, my project is not in a very good state right now |
| 18:57 | <WeirdAl> | that's what happens when it's a spare-time project |
| 18:57 | <WeirdAl> | with MDV, I have to admit I don't grok it |
| 18:58 | <WeirdAl> | I really think a lunch won't be enough time :) |
| 19:00 | <tantek> | grigs et al re: responsive/adaptive images - with so much conversational traffic (email, IRC), it's a bit shocking that more use-cases haven't been fleshed out - questions answered etc.: http://www.w3.org/wiki/Images |
| 19:02 | <Wilto> | tantek: Is the W3C wiki or the WHATWG wiki the most appropriate place for those? |
| 19:02 | <grigs> | tantek: the wiki didn't seem like the right place for my thoughts about the pre-parser and once that idea got into my head, well, it wouldn't go away until i wrote about it. |
| 19:02 | <zewt> | step 1 is mailing list; nobody will ever see stuff on the wiki |
| 19:03 | <tantek> | Wilto - at the time Shane Hudson volunteered to write them up, I said up to him, either is fine, and he chose the URL |
| 19:03 | <tantek> | zewt - no, step one is capture content on the wiki. step 2 is email a URL to said content. |
| 19:03 | <dglazkov> | WeirdAl: then your best bet is probably ramping up on Web Components and MDV and then condensing questions into emails |
| 19:03 | <tantek> | no one sees content on the email list after a week - it's effectively dead and unfindable |
| 19:04 | grigs | thinks we had this conversation about wikis and emails the last week. |
| 19:04 | <tantek> | grigs - pre-parser sounds like a solution approach rather than talking about use-cases to solve. |
| 19:05 | <tantek> | grigs, folks that primarily use email tend to forget the past and make the same errant statements repeatedly (see: every email list). |
| 19:05 | <tantek> | Though I'll add zewt's misconception to the wiki so it can be referenced by URL. |
| 19:05 | <grigs> | lol |
| 19:08 | <grigs> | tantek: i would describe talking about the pre-parser as understanding the technical problem, not talking about a solution approach. the technical problem is why the solutions seem disconnected from the use cases to me. understanding that is helpful. |
| 19:08 | <zewt> | no, send it to the list and stop wasting time with a wiki |
| 19:08 | <zewt> | replace the wiki with tantek's misconception that duplicating stuff on the wiki is useful |
| 19:09 | <tantek> | zewt - if your point is that duplication is bad, I'll accept that |
| 19:09 | grigs | sighs |
| 19:09 | <Wilto> | Ditto. |
| 19:09 | <tantek> | however note that using only/primarily email = duplication over and ove r |
| 19:09 | <tantek> | whereas if you put it on the wiki, you maybe duplicate once, and then subsequently send URLs instead. |
| 19:10 | <tantek> | = less duplication |
| 19:10 | <zewt> | it's a useless way to discuss use cases. |
| 19:10 | <zewt> | tons of use case discussion happens on the list and it works fine. every time someone goes "i'll start a wiki page!" everything gets sidetracked and people waste time. |
| 19:13 | <Wilto> | It doesn’t really seem sustainable as more and more people join in these talks, but I guess this is a little out of my wheelhouse. |
| 19:14 | <tantek> | irc and email are good for asking the question of were/are there any existing discussions of a use-case / topic / feature (since humans can still often find things better conceptually than search engines) |
| 19:14 | <tantek> | so in that regard, email/irc is a good step 1 for asking questions. |
| 19:17 | <WeirdAl> | dglazkov: wrt MDV's bindings, have you guys looked at Harmony proxies for that? |
| 19:17 | <grigs> | Oh hey everyone, in case you’re wondering, I’m apparently at odds with you: http://www.webmonkey.com/2012/05/browsers-at-odds-with-web-developers-over-adaptive-images/ |
| 19:17 | grigs | shakes his head. |
| 19:18 | <zewt> | snr in this topic is miserable, heh |
| 19:18 | <tantek> | Wilto - you're exactly right, email doesn't scale. |
| 19:19 | <dglazkov> | WeirdAl: yep. You really need to talk to rafaelw_ -- he wrote it |
| 19:19 | WeirdAl | sighs |
| 19:19 | <tantek> | fewer and fewer people have the time to keep up with so many conceptual diffs - so the conversation typically devolves into taking sides / opinions, rather than reasoned discussion based on established assumptions (use-cases). |
| 19:19 | <Wilto> | BREAKING NEWS: grigs wants to physically fight everyone in #whatwg; news at 11:00. |
| 19:20 | <Wilto> | (I call first.) |
| 19:20 | <miketaylr> | tabloids gonna tabloid |
| 19:20 | <grigs> | Wilto: i can take you little man. it's the rest of the room i worry about. ;-) |
| 19:21 | <Wilto> | grigs: You at me, at the flagpole, after school. |
| 19:21 | WeirdAl | looks for his .50 cal |
| 19:21 | <grigs> | ok, WeirdAl both just lived up to his namesake and won this fight. |
| 19:22 | <WeirdAl> | you haven't been paintballed until you've been fifty-cal paintballed. |
| 19:22 | <Wilto> | I _am_ deathly allergic to bullets. |
| 19:22 | <tantek> | zewt - evidence that disproves your assertion that "every time someone goes "i'll start a wiki page!" everything gets sidetracked and people waste time." - the Time element enhancements were primarily developed on the wiki, grown quite effectively over time, and used as the source for decision making. http://wiki.whatwg.org/wiki/Time_element |
| 19:22 | <tantek> | Email on the issues were minimal. There was some IRC, and some in-person discussion at TPAC. |
| 19:23 | <zewt> | you're making up a problem that doesn't exist and telling whatwg to change how it works to solve it. sorry; no thanks |
| 19:25 | <zewt> | (and since there isn't actually a problem to solve--email works fine--I don't feel like dedicating much more time debating this at the moment) |
| 19:26 | <Wilto> | Wow. |
| 19:27 | <tantek> | zewt - your behavior seems to contradict your statements. you say "don't feel like dedicating much more time debating this", yet you're the one that brought up the debate with your statement "step 1 is mailing list; nobody will ever see stuff on the wiki". |
| 19:27 | <grigs> | Found it. The url to the last time this channel discussed the merits of email and wikis. http://krijnhoetmer.nl/irc-logs/whatwg/20120515#l-2223 |
| 19:28 | <zewt> | i'm telling people to keep doing things the way they're normally done on whatwg. that's not debating anything; it's just saying how things are normally done. |
| 19:28 | grigs | thinks it must be lunch time somewhere. |
| 19:29 | <tantek> | zewt - the example of the Time element enhancement experience proved that it doesn't matter if a group works primarily by email, it's *still* more efficient to document research on a wiki and then use email only for brief descriptions with links to the wiki documentation. |
| 19:29 | <zewt> | it proves nothing of the kind, but I'm not wasting more time on this today. |
| 19:29 | <tantek> | zewt, perhaps when you have time for more than simple contradiction. |
| 19:30 | <jgraham> | Oh look, in all this metacrap, I almost missed the interesting stuff |
| 19:30 | <zewt> | now you're just being childish (even more reason for me to do something else) |
| 19:30 | <zewt> | jgraham: should we start bolding the interesting stuff? :P |
| 19:30 | <tantek> | zewt, your statement "proves nothing of the kind" is simple contradiction, not an actual argument. |
| 19:31 | <zewt> | it's a statement of fact, which is so straightforward it needs no further explanation. |
| 19:31 | <jgraham> | gsnedders: So, what state is the stuff you pushed in? |
| 19:31 | <tantek> | your statement about "not wasting more time on this" implied you didn't have time for anything more than your previous statement which was merely a simple contradiction. my statement was merely a summary. there was nothing in my statement that indicated any particular age-bias (e.g. "childish"). |
| 19:32 | <zewt> | seems to me that you're just setting out to waste my time, so I'm not replying any further |
| 19:32 | <tantek> | zewt - by raising the debate, you alone are responsible for wasting your time. |
| 19:36 | Ms2ger` | sighs |
| 19:37 | zewt | ROTT god mode yawns |
| 19:40 | <gsnedders> | jgraham: Passes equal number of tests on both Py2 and Py3, excluding a few tests that I think are wrong. |
| 19:41 | <jgraham> | gsnedders: Do you think it's more broken on py3? |
| 19:41 | <gsnedders> | jgraham: I think encoding detection is. |
| 19:44 | <jgraham> | OK. You planning to fix that? |
| 19:45 | <jgraham> | (when you say encoding detection, do you mean meta prescan? Or the other stuff?) |
| 19:45 | <gsnedders> | (The larger thing, inc. meta prescan) |
| 19:45 | <gsnedders> | And BOM detection, etc. |
| 19:46 | <jgraham> | So... is all the python 3 code autogenerated from python 2? |
| 19:46 | <gsnedders> | Yes. |
| 19:47 | <jgraham> | Can we make sure that is documented? :) |
| 19:47 | <gsnedders> | If you're using the royal we ;) |
| 19:47 | <gsnedders> | I'll fix encoding detection when someone gives me tests :) |
| 19:47 | <jgraham> | Not quite :p |
| 19:47 | <jgraham> | Also, can we fix the prescan stuff and still work entirely using 2to3? |
| 19:48 | <gsnedders> | Yes. |
| 19:48 | <jgraham> | What semantics are you assuming for the encoding detection? |
| 19:48 | <gsnedders> | It'll be even more code that'll force us to be Py2.6 only, but it should work fine. |
| 19:48 | <jgraham> | It only gets used if you pass a bytes object? |
| 19:48 | <gsnedders> | I don't know. Whatever we do now. |
| 19:49 | <jgraham> | What we do now probably doesn't make sense |
| 19:49 | <gsnedders> | If we're given a Unicode object, we have encoding ("utf-8", "certain"), having re-encoded it. |
| 19:49 | <gsnedders> | Oh, it certainly doesn't. |
| 19:49 | <gsnedders> | We should probably split stuff out so we have a separate class for the Unicode case. |
| 19:49 | <gsnedders> | And work out how to handle bytes/unicode files. |
| 19:51 | <jgraham> | Yes |
| 19:51 | <jgraham> | I thought I had looked at this when I did the original hand port |
| 19:52 | <jgraham> | But maybe npt |
| 19:52 | <jgraham> | I thought about it at least |
| 19:52 | <gsnedders> | Really I was just doing whatever got us working on Py3 quickest. |
| 19:52 | <gsnedders> | Once I think everything works on Py3, should then move to trying 3to2. |
| 19:54 | <jgraham> | Well we might as well do it more or less right |
| 19:55 | <jgraham> | Anyway, this looks pretty nice |
| 19:55 | <jgraham> | Thanks! |
| 19:55 | <gsnedders> | I mean, I agree we *should* do stuff right. |
| 19:55 | <gsnedders> | But that's more work, and work for another time. |
| 19:56 | <gsnedders> | If I was going to have to rewrite large amounts of stuff, then sure, it would've made sense to do it right, but I didn't, |
| 20:16 | <tantek> | Wilto, it would be good to work on aggregating the use cases on one wiki page - do you have a preference? |
| 20:26 | <Wilto> | tantek: I mean, I’m flexible: whichever is going to be the best received. I’ve got a WHATWG wiki account already, for what that’s worth. |
| 20:27 | <tantek> | Wilto, cool. I'm flexible too - have developed pages in both places. Shane Hudson expressed a preference for the w3.org wiki so I've been most recently contributing there for the responsive image use-cases. |
| 20:28 | <tantek> | So I guess step one - could you take a look at http://www.w3.org/wiki/Images#Responsive_Images_Use_Cases and see if all the use cases you have are covered? |
| 20:28 | <tantek> | (and if not, add more?) |
| 20:29 | <Wilto> | Sure thing. |
| 20:33 | <Wilto> | It doesn’t sound like it’s going to be… especially well-received, is all. |
| 20:34 | <Wilto> | But, “be the change you want to see,” and all. |
| 20:36 | <tantek> | Wilto - nevermind those discouraging adding to wikis. regardless of opinions, wiki pages provide URLs you, I, and anyone else can use to provide citations. |
| 20:36 | <tantek> | (citations in communications, rather than duplicating text) |
| 20:38 | <Wilto> | Sounds good to me. |
| 22:37 | <gsnedders> | Ah, benchmarks. Aren't you wonderful? "ms (slower is better)" |
| 23:28 | <tantek> | and in this week's episode of needlessly reinvented standards, we bring you rel="logo" http://relogo.org/ - subhead: what was wrong with rel="icon" ? |
| 23:29 | <tantek> | or is this perhaps the result of not understanding that you can have multiple rel="icon" links with different mime/content types including SVG? |
![http://somesite.com/temporary/somefile.png"](http://somesite.com/temporary/somefile.png"){kind=link}