| 00:01 | <Philip`> | What's wrong with using <title></title>? That'd allow validators to still tell you when you forgot to put a title in a normal page |
| 00:03 | <hasather> | Philip`: agreed |
| 00:14 | <Hixie> | Philip`: well would <title></title> be acceptable on a normal page? |
| 00:14 | <Hixie> | maybe i should only allow it to be omitted in documents written in data: URIs in <iframe>s |
| 00:18 | <Philip`> | Hixie: It would be no less acceptable than <title>----</title> or anything else that doesn't make sense, and the spec shouldn't require pages to make sense, so it shouldn't require against <title></title> |
| 00:20 | <Philip`> | (Actually, I don't think I believe that) |
| 00:21 | <Philip`> | (but still I don't think the spec can require that you don't write <title></title>, because then people will just write <title> </title> instead, so the effect is the same) |
| 00:21 | <Dashiva> | I don't see how <title></title> can be any worse than <title> </title> |
| 00:22 | <Dashiva> | ... right |
| 00:22 | <Hixie> | and i don't see how omitting it altogether is any worse than either of those |
| 00:23 | <Hixie> | :-) |
| 00:23 | <Philip`> | The practical effect if it's allowed to be omitted is that validators won't tell you when it's omitted, which is bad since usually you don't want to omit it |
| 00:23 | Dashiva | sees ugly parallels to @alt on the horizon |
| 00:23 | <Hixie> | you also don't want to leave it blank :-) |
| 00:23 | <Hixie> | but what do you think of my other suggestion? |
| 00:24 | <Philip`> | and if validators do complain, and you really don't want a title, it's not at all harmful to enter <title></title> |
| 00:24 | <Hixie> | that is, only allowing it to be omitted in documents written in data: URIs in <iframe>s |
| 00:24 | <Philip`> | Making conformance depend on the context of a document seems like a really bad idea |
| 00:24 | <Hixie> | aww |
| 00:24 | <Dashiva> | Hixie: I'm crazy enough to say that nobody is going to validate an iframe data:URI anyhow :) |
| 00:24 | <Hixie> | i would hope that hsivonen will make his validator check any data: URIs for conformance |
| 00:24 | <Hixie> | including nested ones :-) |
| 00:24 | <Philip`> | hsivonen was complaining about conformance depending on resources that the document links to, so I don't imagine he'd be happy if it depended on resources linking to the document :-) |
| 00:24 | <Hixie> | in due course eventually of course |
| 00:25 | <Hixie> | you know, when he adds CSS support, etc |
| 00:25 | <Dashiva> | I just don't think the use case is worth the special casing |
| 00:25 | <Hixie> | so the use case here is making it easy to use <iframe>s to sandbox blog comments |
| 00:26 | <Dashiva> | And I posit that such comments are autogenerated, and therefore can autogenerate <title>Comment by DudeMan</title> |
| 00:26 | <Hixie> | I want to allow, e.g.: <iframe seamless sandbox src="data:text/html,I don't like you!"></iframe> |
| 00:26 | <Philip`> | Including non-quirks mode stuff? |
| 00:26 | <Hixie> | and <iframe seamless sandbox src="data:text/html,Please buy our <a href='http://example.com/'>porn</a>."></iframe>; |
| 00:26 | <Dashiva> | haha |
| 00:26 | <Hixie> | i guess we would require <!DOCTYPE HTML> |
| 00:27 | <Dashiva> | I don't think I ever saw porn spam that didn't claim to be free |
| 00:27 | <Philip`> | If you're already requiring at least the "data:text/html,<!DOCTYPE HTML>' boilerplate, it doesn't seem hard to add '<title></title>' too |
| 00:27 | <Hixie> | i was just showing the embedded markup, don't bikeshed my example :-P |
| 00:28 | <Hixie> | Philip`: yeah, i guess |
| 00:28 | <Dashiva> | data:text/bikeshed;blue |
| 00:28 | <Hixie> | Philip`: but that's sad |
| 00:28 | <Philip`> | and everybody would want to write 'data:text/html,<!DOCTYPE HTML><html><head><title></title></head><body>...</body></html>' anyway because they don't like optional tags |
| 00:29 | <Hixie> | Philip`: i could get away with making the doctype optional too, and making "sandbox" force strict mode maybe |
| 00:31 | <Dashiva> | You're trying to make poor henry cry, aren't you |
| 00:32 | <Hixie> | people aren't going to like boilerplate before every comment |
| 00:32 | <Hixie> | hm |
| 00:32 | <Hixie> | actually |
| 00:33 | <Hixie> | i'm going to have to make the quirks mode inherit anyway |
| 00:33 | <Hixie> | because the style sheets will be mixed in from the parent |
| 00:33 | <Philip`> | I wouldn't mind boilerplate - that's what programming languages have variables for, so I'll only ever have to write it once |
| 00:34 | <Dashiva> | I wouldn't put it past authors to add stylesheets to the data uri too |
| 00:35 | <Hixie> | that's fine i guess |
| 00:35 | <Philip`> | Is it an Opera bug that data:text/html,a#b results in "a"? |
| 00:35 | <takkaria> | the prospect of data urls inside data urls inside data urls terrifies me |
| 00:36 | <Hixie> | Philip`: i believe not |
| 00:36 | <Hixie> | takkaria: i've used them often |
| 00:36 | <takkaria> | "often"? :) |
| 00:36 | <Hixie> | e.g. for graphics in style sheets in html documents |
| 00:36 | <Hixie> | well, you know |
| 00:36 | <Philip`> | Hixie: Oh; then doesn't that mean you'll needs lots of fiddly escaping to make sure the constructed data: URIs work right? |
| 00:36 | <Hixie> | sometimes |
| 00:36 | <Philip`> | and then they won't be human-readable any more, so you might as well use base-64 |
| 00:37 | <Hixie> | Philip`: you'll need to escape two characters, #, and the character used for quoting the attribute |
| 00:38 | <Hixie> | Philip`: if people forget to quote the ", then it'll be quickly obvious (long before security problems, probably) |
| 00:38 | <Hixie> | oh and %s i guess |
| 00:38 | <Philip`> | Hixie: And & |
| 00:38 | <Hixie> | and & |
| 00:38 | <Hixie> | hm |
| 00:38 | <Hixie> | crap |
| 00:38 | <Hixie> | four characters is a problem |
| 00:39 | <Hixie> | we could introduce a brand new way of embedding data, but then it'll not be backwards compatible... |
| 00:40 | <Philip`> | Hmm, isn't non-backward-compatibility a good thing here? Otherwise a site using <iframe sandbox src="data:..."> will expose users in old browsers to all sorts of security issues that the sandbox was meant to prevent |
| 00:40 | <Hixie> | well, the sandbox is an extra level of security |
| 00:41 | <Hixie> | in the transition period it doesn't add much |
| 00:41 | <Philip`> | and anyway data:text/html,... won't be compatible with IE6/7, and maybe not with IE8 either, so in practical terms there's no backward compatibility |
| 00:41 | <Hixie> | oh, true |
| 00:41 | <Hixie> | i keep forgetting how much IE sucks |
| 00:41 | <Dashiva> | <sandbox> here we go |
| 00:42 | <Hixie> | we're using <iframe>s for many other reasons |
| 00:42 | <Hixie> | but we don't have to use src="" on <iframe> for embedding data inline |
| 00:43 | <Philip`> | Hixie: If the feature adds any security, some authors will start relying on that security (perhaps without considering all the implications in legacy/buggy UAs), and then some users (of legacy/buggy UAs) will suffer because of that |
| 00:44 | <Philip`> | which doesn't seem like good security design |
| 00:44 | <Dashiva> | So like @safesrc then |
| 00:44 | <Philip`> | Dashiva: I thought the point was that the source was *un*safe, hence needing all this protection around it :-) |
| 00:45 | <Hixie> | Philip`: yeah well |
| 00:46 | <Hixie> | Philip`: good security design in this case is somewhat mutually exclusive with what people actually want |
| 00:46 | <Dashiva> | Philip`: It's a safe you put the src in |
| 00:47 | <Hixie> | but what i was actually thinking of is a custom parse mode for an iframe "attribute" |
| 00:47 | <Philip`> | <iframe src=<<EOF> |
| 00:48 | <Hixie> | <iframe data=", and then anything but " will be treated literally, "" will be treated as a single ", and a single " will close it |
| 00:48 | <Philip`> | (Yay here-docs) |
| 00:48 | <Hixie> | heredocs are hard to escape |
| 00:49 | <Hixie> | you have to be able to guarentee that you have a non-predictable random number generator |
| 00:50 | <Philip`> | What's the problem with using base64? These comment systems are always going to be generated dynamically, and all languages have a trivial way to base64-encode some data, and then it's easy to see that you've got it right (rather than having to worry about whether there's a character you forgot to escape) |
| 00:50 | <Hixie> | people were not happy with stuff you couldn't look at in view source |
| 00:51 | <Hixie> | when i suggested that |
| 00:51 | <Philip`> | Browser developers need to make 'view source' cleverer so it auto-expands base64 |
| 00:52 | <Hixie> | browser developers have bigger fish to fry |
| 00:52 | <Dashiva> | Fancy encodings are a pickle |
| 00:52 | <Dashiva> | Take percent-encoding in URLs when displaying the URL in the status bar |
| 00:53 | <Philip`> | <iframe data="normal HTML attributes with escaped & and " and not % or #"> seems easier to understand, and is compatible with all existing HTML parsers and editors and syntax highlighters and libraries and everything |
| 00:53 | <Hixie> | that might work |
| 00:54 | <Hixie> | though the failure mode for not doign & isn't obvious |
| 00:54 | <Philip`> | It's only two characters to escape, or $cgi->escapeHTML(...) or [% ... | html %] or whatever |
| 00:55 | <Hixie> | yeah |
| 00:55 | <Philip`> | The failure mode for not doing & is not a security issue |
| 00:56 | <Philip`> | ...so it's still annoying but not fatally so |
| 00:56 | <Hixie> | sure it is |
| 00:56 | <Philip`> | Not doing " is a more severe problem but it's also pretty much impossible to miss when you get it wrong |
| 00:57 | <Hixie> | oh hm actually no it isn't, you're right |
| 00:57 | <Hixie> | yeah forgetting to quote " is no issue |
| 00:57 | <Hixie> | othermaciej_ needs to do something about his network |
| 00:57 | <Hixie> | i'd go insane if i had a network like that |
| 01:00 | <Philip`> | Hixie: Perhaps he *has* gone insane |
| 01:00 | <Hixie> | true |
| 01:02 | <Hixie> | an attribute might work... hmm... |
| 01:02 | <Hixie> | what should we call it |
| 01:02 | <Hixie> | data="" is bad due to <object data> being a URI |
| 01:02 | <Philip`> | <iframe src2="..."> |
| 01:02 | <Hixie> | <iframe markup=""> ? |
| 01:03 | <Hixie> | and markup="" can override src="" |
| 01:03 | <Philip`> | content |
| 01:03 | <Hixie> | that way you can set both for legacy UAs |
| 01:03 | <Hixie> | content="" is good |
| 01:03 | <Hixie> | but it takes markup |
| 01:03 | <Hixie> | and <meta content> doesn't |
| 01:03 | <Dashiva> | Is there anything that takes markup at the moment? |
| 01:03 | <Hixie> | no |
| 01:03 | <Philip`> | Yes |
| 01:03 | <Hixie> | other than href="" and src="" and data="" |
| 01:04 | <Philip`> | The contents of most elements takes markup |
| 01:04 | <Hixie> | element markup |
| 01:04 | <Hixie> | in attributes |
| 01:04 | <Hixie> | is what i assume Dashiva meant |
| 01:04 | <Dashiva> | Yes |
| 01:05 | <Hixie> | i wish we could use the actual content of <iframe>s but the <!-- parsing behaviour is just inane |
| 01:05 | <Philip`> | What's the fallback behaviour in current UAs for <iframe not-src-attribute>text</iframe>? |
| 01:06 | <Hixie> | same as src=about:blank |
| 01:06 | <Philip`> | like, could you put a stripped plain-text version of the comment in there, to have it work (though uglier) for all users? |
| 01:06 | <Philip`> | Oh |
| 01:07 | Philip` | doesn't like the attribute name "markup" because it doesn't make him realise that it's giving the content of the iframe |
| 01:07 | <Hixie> | yeah |
| 01:07 | <Hixie> | i don't like it either |
| 01:08 | <Hixie> | <iframe data value content> are all taken already for other uses and would be confusing |
| 01:08 | <Hixie> | <iframe source> is too much like src |
| 01:08 | <Dashiva> | src2 is too much like http? ;) |
| 01:08 | <Hixie> | src2 doesn't convey why it s different from src |
| 01:09 | <Hixie> | <iframe subdocument=""> ? |
| 01:09 | <Hixie> | <iframe doc=""> ? |
| 01:09 | <Philip`> | Leave it unspecified for now and then use implementation experience to determine what name to settle on |
| 01:09 | <Dashiva> | That sounds like something |
| 01:09 | <Hixie> | Philip`: :-) |
| 01:09 | <Hixie> | Philip`: that doesn't work so well for things like this |
| 01:10 | <Hixie> | <iframe html=""> ? |
| 01:10 | <Hixie> | i wonder how to deal with this xhtml vs html issue here |
| 01:10 | <Philip`> | What about XHTML? |
| 01:10 | <Philip`> | Good point! |
| 01:11 | Hixie | would be happy to not deal with it :-D |
| 01:12 | <Lachy> | what's the purpose of this new attribute for iframe?? |
| 01:12 | <Hixie> | Lachy: a way of including arbitrary blog comments sandboxed |
| 01:13 | <Dashiva> | srcml? |
| 01:13 | <Lachy> | ok, I'll go read the irc logs... |
| 01:14 | <Hixie> | heh, not sure it'll help :-) |
| 01:14 | <Hixie> | doc="" and html="" are the main contenders i think |
| 01:15 | <Lachy> | regarding this: <Hixie> i think <title> should be made optional for documents intended to be used inside iframes |
| 01:16 | <Lachy> | doesn't assistive technology read out the title of documents in frames? |
| 01:16 | <Hixie> | not when the seamless="" attribute is specified |
| 01:16 | <Philip`> | Lachy: It's not too late to pretend you never mentioned accessibility here |
| 01:16 | <Lachy> | what's the seamless attr? |
| 01:17 | <Dashiva> | Probably to make it not look like an iframe |
| 01:17 | <Hixie> | Lachy: an attribute to make iframes work like client-side includes |
| 01:19 | <takkaria> | Dmitry would be happy |
| 01:21 | <Philip`> | Can you do <!doctype html><iframe seamless src=header.html></iframe>blah blah<iframe seamless src=footer.html></iframe>? |
| 01:21 | <Hixie> | yup |
| 01:21 | <Hixie> | and clicking on links in header.html will navigate the parent frame |
| 01:22 | Philip` | can't decide whether that's a good thing or a bad thing |
| 01:22 | <Hixie> | why would it be bad? |
| 01:22 | <Hixie> | people have been asking for it for decades |
| 01:22 | <Hixie> | even in the 70s people were saying html should support it |
| 01:22 | <Dashiva> | The idea is to have in-document content with outside-document security, isn't it? |
| 01:23 | <Hixie> | though i think that may have just been some poor research on the behalf of time travellers |
| 01:23 | <Philip`> | People have been asking for flying cars for decades and it'd still be a terrible idea because it'd be abused far too much |
| 01:23 | <Hixie> | ground cars are a bad idea too, but we still have those :-) |
| 01:23 | <Hixie> | Dashiva: that's another part of the current work i'm doing, but it's not seamless="" |
| 01:23 | <Hixie> | Dashiva: that's the sandbox="" part |
| 01:24 | <Philip`> | We're stuck with the legacy of ground cars, but that's no reason to make things worse by making cars that far harder to drive |
| 01:24 | <Philip`> | s/ / are/ |
| 01:26 | <Hixie> | flying cars don't have to be manual-drive |
| 01:26 | <Hixie> | they could be automated |
| 01:27 | <Dashiva> | Flying cars are better than people strapping jet engines on their ground cars |
| 01:27 | <Hixie> | (actually that would be easier than making ground cars automated) |
| 01:27 | <Philip`> | I think there's more problems in a flying car than the manual gearbox :-p |
| 01:28 | <Philip`> | I wouldn't like to be stuck in rush hour on a windy day |
| 01:28 | <Hixie> | (first, flying automated vehicles are far easier than ground vehicles, and the AI is far more advanced today; and second, there's little legacy to deal with) |
| 01:28 | <Hixie> | gotta go |
| 01:28 | <Hixie> | bbl |
| 01:29 | <Philip`> | Also, automated cars always lock you in and kill you |
| 01:29 | <Dashiva> | Is that a rule? |
| 01:29 | <Philip`> | Yes |
| 01:29 | <Philip`> | Just watch TV |
| 01:29 | <Dashiva> | I remember the cab I took in Japan locked the doors |
| 01:29 | <Dashiva> | But it wasn't automated |
| 01:29 | <Dashiva> | And it took me to the dentist instead of killing me |
| 01:29 | <Philip`> | Did poison gas start hissing out of the dashboard? |
| 01:30 | <Dashiva> | No, and it was cheap too |
| 01:30 | <Philip`> | Oh |
| 01:30 | <Philip`> | I guess real life doesn't live up to the expectations provided by TV :-( |
| 01:30 | <Dashiva> | The driver could have been an android, though. |
| 01:39 | <takkaria> | Doctor Who had the automated-car-locks-in-and-kills-people thing recently |
| 01:40 | <Dashiva> | I don't think it's really limited to cars. Automated houses tend to do the same, don't they? |
| 01:41 | <takkaria> | not had as much experience with them |
| 01:48 | <Philip`> | takkaria: That's the one I was thinking of :-) |
| 11:31 | <annevk> | http://lists.w3.org/Archives/Public/public-xhtml2/2008May/0049.html ... |
| 12:08 | <hsivonen> | Hixie: Validator.nu should check data URIs for conformance but not nested ones |
| 12:09 | <hsivonen> | (and, yes, Hixie's data URIs are non-conforming for having spaces) |
| 12:12 | <hsivonen> | Hixie: "should" as in "I think it already does, if it doesn't, it's a bug" |
| 12:12 | <hsivonen> | that is, data URIs are checked for data URI level conformance |
| 12:12 | <hsivonen> | the payload is not checked |
| 14:04 | <MikeSmith> | http://blog.whatwg.org/vim-checker |
| 14:04 | <MikeSmith> | just published |
| 14:06 | <Lachy> | wow! Do people still use vim? |
| 14:12 | <MikeSmith> | Lachy: only smart people :) |
| 14:29 | <MikeSmith> | the term "Grouping content" doesn't seem to be defined anywhere is the spec |
| 14:29 | <MikeSmith> | only as the title of what used to be the "Prose" elements section |
| 14:31 | <MikeSmith> | but since what was called "prose content" is now "flow content", maybe the "Grouping content" section should be titled "Flow content" .. |
| 14:34 | <MikeSmith> | hmm, no |
| 14:34 | <MikeSmith> | I see that all "phrasing content" is also by definition "flow content" |
| 14:36 | <MikeSmith> | maybe "Grouping content elements are those used to group together runs of phrasing content into logical structures such as paragraphs and lists." |
| 15:48 | <hendry> | MikeSmith: did you see http://natalian.org/archives/2008/05/17/vim-web-ide/ |
| 15:48 | <hendry> | i should have cut the screencast into 3 parts. as the validator.nu part I screwed up. |
| 15:49 | <hendry> | Lachy: if you're in London we could meet up. I won't be going to @media mind |
| 15:55 | <MikeSmith> | hendry: saw it but dint watch the video yet |
| 15:59 | <hendry> | MikeSmith: video editing is such a pain in Debian. Cinerella does not work for me. |
| 16:00 | <MikeSmith> | I have long ago given up on trying to do much with video or audio under Linux |
| 16:00 | <MikeSmith> | even playing |
| 16:00 | <Philip`> | I used Blender for video editing once |
| 16:00 | <hendry> | heh, well... there must be some good video editing web application |
| 16:00 | <Philip`> | It actually sort of worked, once I learned what actions would crash it |
| 16:00 | <hendry> | (flash application mind) |
| 16:01 | <hendry> | Philip`: heh |
| 16:01 | <Philip`> | and also I had to compress my input videos because it didn't like 2GB files, if I remember correctly |
| 16:02 | <MikeSmith> | avoiding video and audio problems under Linux was one of the best side of effects for me of moving away from Linux-only laptop to a MacBook and running Debian and Windows on it under VMs |
| 16:03 | <Philip`> | and it was a bit akward to use for a minute-long video with only about eight video tracks, so I wouldn't want to use it for anything more complex |
| 16:04 | <hendry> | MikeSmith: i have no problems with playback |
| 16:13 | <Philip`> | Should <a href="1.2.3.4:5"> be interpreted as an absolute or relative URI? |
| 16:14 | <Philip`> | (Firefox thinks relative; Opera thinks absolute, which breaks a link on http://ms.aybab2u.com:8080/ ) |
| 16:15 | <takkaria> | relative, blatantly |
| 16:16 | <Philip`> | IE thinks "invalid syntax error" |
| 16:18 | <Dashiva> | Philip`: It's the old ": means schema", isn't it? |
| 16:19 | <Dashiva> | No, port |
| 16:20 | <Philip`> | I don't know what it is, except that it's annoying that it breaks :-) |
| 16:21 | <Dashiva> | Probably isn't relevant, actually, since it dealt with manually entering an address |
| 16:29 | <MikeSmith> | hendry: got your mail, changes made |
| 16:31 | <hendry> | MikeSmith: thanks |
| 16:32 | hendry | wonders if it's possible to link 2mins into a video /myvid.ogg?min=2 |
| 16:34 | <hdh> | alternate video/audio streams too |
| 16:37 | <hendry> | can't find anything on youtube. i think it was possible on google video. |
| 16:40 | MikeSmith | looks around for kfish |
| 16:40 | <MikeSmith> | this is what annodex is for, I guess |
| 16:41 | <MikeSmith> | Xiph |
| 16:41 | <hdh> | henry: looks like it broke sometime ago http://groups.google.com/group/google-video-general/browse_thread/thread/f7645bab2595ce8c |
| 16:43 | <hendry> | hdh: good hunting |
| 16:43 | <hdh> | thx, I searched the help center |
| 16:50 | <hdh> | is there a google custom search (or similar) for all html5 sources (mailing-list, irc, the spec)? |
| 16:54 | <hendry> | hdh: not that I know of. good idea. start it and invite me :) |
| 16:56 | <hdh> | whatwg.org, html5.org, krijnhoetmer.nl/irc-logs/*, *.w3.org/html/wg/html5/*; any more to add? |
| 16:57 | <hdh> | lists.w3.org/Archives/Public/www-html/*, lists.w3.org/Archives/Public/www-html-testsuite/* |
| 16:58 | <MikeSmith> | hdh: http://www.w3.org/html/ |
| 17:03 | <hdh> | http://www.google.com/coop/cse?cx=012969598209138263813:exzxsykptac |
| 17:09 | <hendry> | hdh: I would prefer it only searched http://www.whatwg.org/specs/web-apps/current-work/multipage/ not http://www.whatwg.org/specs/web-apps/current-work/ |
| 17:10 | <Philip`> | Does Google index whatwg.org/issues? |
| 17:11 | <hdh> | heh, I can't change any setting (the page says "Save failed") |
| 17:11 | <Dashiva> | Philip`: You mean if it indexes the contents of the script? :) |
| 17:11 | <Philip`> | Looks like it probably doesn't, in which case there's http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/ , though that shouldn't actually have anything that's not on the mailing lists |
| 17:12 | <Philip`> | Dashiva: I mean indexing the data that script gets from its custom API via XHR :-) |
| 17:12 | <Dashiva> | I'm pretty sure we'll know very soon if the google spider starts executing scripts :) |
| 17:13 | <Philip`> | It does statically follow link-like strings in scripts |
| 17:13 | <Philip`> | but it's very dumb about it |
| 17:14 | <Philip`> | so it's not quite at the level of embedding a JS interpreter and DOM implementation |
| 17:18 | <hendry> | hdh: i had the same problems in firefox. switch to webkit. |
| 17:21 | hsivonen | is mildly amused to see <tt> instead of <code> on the WHATWG wiki |
| 17:27 | <hsivonen> | hmm. I wonder if I should just implement the SVG stuff now that I'm looking at the MathML stuff anyway... |
| 17:30 | <hsivonen> | yeah, I should |
| 17:32 | <hsivonen> | we need to extend the tree builder test format to cover SVG and MathML |
| 17:42 | <hdh> | I have set the CSE to allow volunteers |
| 17:55 | <hdh> | "Status: Error: OK (403)." <-- the error message when login to annotate system fails, that OK looks weird |
| 18:53 | <Philip`> | hsivonen: "Validator.nu should check data URIs for conformance but not nested ones (and, yes, Hixie's data URIs are non-conforming for having spaces)" - should it be checking that in http://validator.nu/?doc=data%3Atext%2Fhtml%2Ca+b too? |
| 18:53 | <Philip`> | (Sadly WF2 causes functional regressions when implemented, so you can't test the validator like that in Opera) |
| 18:56 | <hsivonen> | Philip`: what's your opinion? should I make it whine about the URI in that case? |
| 18:56 | <hsivonen> | Philip`: when I wrote the code, I figured that in this case Validator.nu is acting as a general app accepting data URIs rather than as a checker |
| 18:57 | <Philip`> | hsivonen: That sounds sensible - it's more useful if the validator works than if it doesn't work |
| 18:58 | <Philip`> | Then again, it's a validator so it's useful if it tells you when you're doing something invalid |
| 18:59 | <Philip`> | So, uh, I don't know |
| 19:04 | Philip` | discovers that a todo list which he's never going to read in the future is actually still useful - when the effort of writing the todo entry is comparable to the effort of actually doing the task, it encourages him to just do the task |
| 21:49 | <Hixie> | hsivonen: i meant check the payload. i was thinking of making spaces legal, but a new attribute is a better idea. |
| 22:17 | <Philip`> | Does anyone happen to know what license the Creative Commons licenses themselves are under? |
| 22:17 | <Philip`> | (e.g. is it allowed to take the CC license text and modify it a bit?) |
| 22:26 | <bradee-oh> | Hixie: around? |
| 22:32 | <Dashiva> | Philip`: I don't see how a licence would need licensing. Patents, maybe, but copyright? |
| 22:51 | <Philip`> | Dashiva: It needs copyright licensing as much as any other textual document needs it |
| 22:52 | <Philip`> | The GPL explicitly allows copying and distribution but not modification (presumably to prevent the confusion of not-quite-GPL licenses based on it), but I can't find any similar information about CC licenses |
| 22:55 | <Dashiva> | Sure, but there's a significant difference between the specific text of the GPL preamble and saying "You are allowed to copy my stuff if you give props" |
| 22:56 | <annevk> | Hmm, MikeSmith' post makes me want to try Vim |
| 22:56 | <Dashiva> | annevk: What are you using atm? |
| 22:58 | <annevk> | komodo and gedit |
| 22:59 | <annevk> | and whatever else has syntax highlighting and reasonable undo/redo history |
| 23:05 | <annevk> | I wonder how difficult it would be to write a plugin for Dreamweaver that uses Validator.nu |
| 23:05 | <annevk> | or for Komodo for that matter |
| 23:06 | <jgraham> | Komodo would be pretty easy I think. |
| 23:06 | <jgraham> | Plugins are javascript |
| 23:07 | <jgraham> | Has someone integrated validator.nu into emacs yet? |
| 23:08 | <Dashiva> | annevk: How about getting it into opera? ;) |
| 23:17 | <Philip`> | jgraham: Someone must have written a JVM in Emacs Lisp, so you could just run the validator in that |
| 23:18 | <jgraham> | Philip`: Always the one with the over complex solution :) |
| 23:25 | <Hixie> | bradee-oh: vaguely |
| 23:27 | <bradee-oh> | Hixie: I emailed my question to whatwg... but it's kind of bewildering, I was hoping you could clear up some concerns in short fashion, if you're awake and all that stuff ;) |
| 23:28 | <Hixie> | as you note in your e-mail, that mailing list won't affect the webidl spec |
| 23:28 | <Hixie> | but yes, [XXX] is for making a [[Delete]] function work |
| 23:28 | <Hixie> | but how does the WebIDL spec differ from what we had? |
| 23:29 | <Hixie> | the intent was not to not change anything substantial |
| 23:29 | <bradee-oh> | Hixie: well, the problem is... the passage we had about enumerating the keys of a storage object... I can't find how the WebIDL spec keeps that functionality in place. |
| 23:29 | <bradee-oh> | maybe I'm misreading WebIDL or just glazing over the appropriate section |
| 23:29 | <Hixie> | oh hm |
| 23:30 | Hixie | looks at webidl and es3 |
| 23:31 | <Hixie> | uh yeah, oops |
| 23:31 | <Hixie> | webidl doesn't seem to support this |
| 23:31 | <Hixie> | will fix |
| 23:31 | <bradee-oh> | Hixie: woohoo! |
| 23:31 | <bradee-oh> | Hixie++ |
| 23:31 | <bradee-oh> | though to be fair... |
| 23:31 | <bradee-oh> | Hixie-- for the original removal ;) |
| 23:32 | <bradee-oh> | Hixie++ // for being such a super guy |
| 23:32 | <bradee-oh> | thanks! |
| 23:32 | <Hixie> | heycam: we have a problem with webidl |
| 23:33 | <Hixie> | heycam: there doesn't seem to be a way to say that all the members should be DontEnum but that a certain set of properties should be added (that aren't in the IDL) for the purposes of for-in enumeration |
| 23:34 | <Hixie> | bradee-oh: the fix might take a while, just assume it will happen. if you really need the spec fixed (e.g. because someone is arguing with you) then let me know in a couple of days if i haven't yet done it |
| 23:34 | <Hixie> | bradee-oh: (i'm in the middle of some other edits) |
| 23:35 | <bradee-oh> | Hixie: assurances that it will happen is good enough for me. I'll check up on it later this week. thanks! |
| 23:35 | <Hixie> | np |
| 23:38 | <heycam> | Hixie, yeah i just saw that mail from bradee-oh |
| 23:38 | <Hixie> | cool |