| 07:56 | <hsivonen> | looks like I should redeploy V.nu |
| 08:13 | <MikeSmith> | hsivonen: yeah, a few changes went in last week |
| 08:38 | <hsivonen> | the design of http://xkcd.com/ is awesome today |
| 08:40 | <annevk42> | source code too |
| 08:40 | <annevk42> | <HTML WEB="2.0"> |
| 08:40 | <annevk42> | <SCRIPT LANGUAGE="QBASIC">IF $BROWSER = "IE" THEN GOTO 50</SCRIPT> |
| 08:41 | <annevk42> | and as Netscape icon it has the one from IE |
| 08:41 | <annevk42> | good stuff :) |
| 08:43 | <hsivonen> | has MS announced something about implementing HTML5 forms in IE9? |
| 08:44 | <annevk42> | not that I know |
| 08:45 | <annevk42> | but I'm a little out of the loop |
| 08:46 | <hsivonen> | I just noticed an interesting parity-IE annotation on b.m.o |
| 08:47 | <annevk42> | pointer? |
| 08:47 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=344614 |
| 08:48 | <annevk42> | seems you can ask a colleague about it |
| 08:50 | <annevk42> | heh, Gmail is using <input type=url>, didn't know |
| 09:01 | <hsivonen> | MikeSmith: I'm about to check in a version of build.py that uses the hg repo for the htmlparser. |
| 09:01 | <hsivonen> | MikeSmith: is there anything I should do to make it suck less for users who already have an svn checkout of the parser? |
| 09:02 | hsivonen | has no idea what happens if one tries to do a hg pull onto a location that already has an svn sandbox |
| 09:05 | <zcorpan_> | Hixie: comment box is broken |
| 09:05 | <MikeSmith> | hsivonen: no clue from me.. but if you go ahead and check it in, I'll test it right away |
| 09:05 | <hsivonen> | what does "private repositories" mean on bitbucket? |
| 09:05 | <MikeSmith> | zcorpan_: that's probably because W3C bugzilla is down |
| 09:05 | <MikeSmith> | or maybe |
| 09:06 | <zcorpan_> | ok |
| 09:06 | <hsivonen> | MikeSmith: OK. committed |
| 09:06 | <Philip`> | hsivonen: I believe it means ones that aren't public |
| 09:06 | <Philip`> | and only authorised users can read |
| 09:07 | <hsivonen> | Philip`: you mean like non-Open Source? |
| 09:08 | <zcorpan_> | Philip`: did you see my suggestion for "further research"? :) |
| 09:08 | <hsivonen> | my use cases are: 1) Making a staging repo for the hg.mozilla.org htmlparser repo and 2) moving all the rest of the V.nu repos to hg |
| 09:09 | <hsivonen> | are there other hg hosting providers besides bitbucket and Google Code? |
| 09:09 | <hsivonen> | Google insists on one license per repo, right? |
| 09:09 | <hsivonen> | so Google is out of question |
| 09:09 | <Philip`> | hsivonen: You can give people read access to non-OS code, and you can not give read access to OS code, so those seem unrelated concerns |
| 09:10 | <Philip`> | I don't believe Bitbucket has any licensing requirements on any type of repository |
| 09:11 | <hsivonen> | so assuming other committers are OK with BitBucket, would BitBucket be sensible or is there something awful I should be aware of? |
| 09:11 | <Philip`> | (The only constraint is you can't stop people reading public repositories) |
| 09:12 | <Philip`> | hsivonen: I've only used it a tiny bit but it seemed to work alright |
| 09:12 | <Philip`> | It seems like it shouldn't be an important decision, because you can simply clone the repository and move it somewhere else whenever you want |
| 09:16 | <Philip`> | zcorpan_: If someone can tell me how to make validator.nu parse with scripting enabled, it should be easy enough to do |
| 09:17 | <jgraham> | hsivonen: I have never heard anything bad about bitbucket |
| 09:17 | <zcorpan_> | hsivonen: how does Philip` make v.nu parse with scripting enabled? |
| 09:18 | <Philip`> | jgraham: That could be because you have never heard anything about it at all |
| 09:18 | <jgraham> | Philip`: Indeed. However I have heard some things about it. SO it's not that |
| 09:19 | <hsivonen> | Philip`, jgraham: thanks for comments about bitbucket |
| 09:19 | <hsivonen> | zcorpan_: do you mean parsing with the "scripting enabled" bit set or do you mean actually running scripts? |
| 09:20 | Philip` | more recently just set up hgweb.cgi on his own server because it seemed easier (and less restrictive of disk space) than using external providers |
| 09:20 | <zcorpan_> | hsivonen: the former |
| 09:20 | <hsivonen> | Philip`: I want professionals to take care of backups for me |
| 09:20 | <Philip`> | hsivonen: "hg pull" should take care of backups |
| 09:20 | <Philip`> | unless I'm missing something |
| 09:21 | <hsivonen> | Well, I suppose I could have the repos on validator.nu and have a cron job on html5.validator.nu pulling them as backups |
| 09:22 | jgraham | has hgweb set upfor various things |
| 09:23 | <jgraham> | but not for anything really useful |
| 09:23 | <hsivonen> | zcorpan_: the various API wrapper objects for the V.nu parser have a setScriptingEnabled() method |
| 09:24 | <hsivonen> | passing true should do the trick |
| 09:24 | <zcorpan_> | http://about.validator.nu/htmlparser/apidocs/nu/validator/htmlparser/dom/HtmlDocumentBuilder.html#setScriptingEnabled(boolean) ? |
| 09:24 | <hsivonen> | zcorpan_: yes |
| 09:24 | <zcorpan_> | Philip`: ^ |
| 09:26 | <Philip`> | zcorpan_: Tell hsivonen thanks |
| 09:26 | <zcorpan_> | hsivonen: thanks |
| 09:27 | <Philip`> | (from me) |
| 09:27 | <hsivonen> | zcorpan_, Philip` : you're welcome |
| 09:27 | <MikeSmith> | hsivonen: I guess I need to whack my existing htmlparser directory before running the build script? |
| 09:28 | Philip` | wishes the documentation for all this stuff like setScriptingEnabled said what the default was |
| 09:28 | <hsivonen> | MikeSmith: probably |
| 09:28 | <MikeSmith> | OK |
| 09:29 | <zcorpan_> | maybe the default for setScriptingEnabled should be true |
| 09:30 | <hsivonen> | zcorpan_: why? |
| 09:30 | <Philip`> | zcorpan_: What elements do you want searched for? |
| 09:31 | <zcorpan_> | Philip`: script and noscript |
| 09:31 | <Philip`> | zcorpan_: and no others? |
| 09:31 | <zcorpan_> | Philip`: right |
| 09:32 | <zcorpan_> | hsivonen: i guess it depends on what people expect the default to be |
| 09:32 | <jgraham> | hsivonen: My expectation is that non-browsxer applications that do not support scripting are expected to behave more like the scripting enabled case but not run scripts |
| 09:33 | <hsivonen> | clearly, this <noscript> thing isn't a winner design |
| 09:33 | <Philip`> | zcorpan_: Running... |
| 09:33 | <zcorpan_> | cool |
| 09:33 | <Philip`> | (Might take a while) |
| 09:37 | <zcorpan_> | maybe there are pages with <noscript><!--</noscript>FOO<noscript>--></noscript> |
| 09:37 | <zcorpan_> | although that wouldn't be too useful since it'd always be hidden |
| 09:37 | <zcorpan_> | (today) |
| 09:39 | <Philip`> | Hmm, there's quite a lot of <script> textContent |
| 09:40 | <MikeSmith> | hsivonen: so, I think the current build script isn't going to work for initial checkout |
| 09:40 | <MikeSmith> | I think for initial checkout, it needs to do an hg clone |
| 09:40 | <hsivonen> | aargh |
| 09:41 | <zcorpan_> | Philip`: i think that's expected |
| 09:41 | <hsivonen> | good point |
| 09:41 | <hsivonen> | sorry |
| 09:41 | <MikeSmith> | np |
| 09:41 | <MikeSmith> | hsivonen: I'm going to drop off for a bit but will be back on later |
| 09:41 | <zcorpan_> | maybe there are pages with <noscript><!--</noscript>FOO<noscript>--!></noscript> |
| 09:41 | hsivonen | wonders what happens if hg clone is done over an existing clone |
| 09:42 | <zcorpan_> | which would trigger reparsing with scripting enabled but hide the FOO with scripting disabled |
| 09:42 | <jgraham> | hsivonen: You can presumably rather easilly check if you have an existing repository |
| 09:43 | <Philip`> | hsivonen: I think it might complain that the target directory already exists |
| 09:43 | <jgraham> | (at the very least you can look for a .hg; if you are using the api then you can probably do something more fancy) |
| 09:44 | <zcorpan_> | Philip`: if <script> textContent is several hundred, then it's probably right; if it is several thousand then it might be something wrong |
| 09:45 | <Philip`> | So far I don't see any noscript with "</noscript" in it |
| 09:46 | <zcorpan_> | that's good :) |
| 09:47 | <Philip`> | Assuming it's not an error in the parser or in my scripts :-) |
| 09:49 | hsivonen | tries to figure out how to run hg pull from outside the local repo |
| 09:49 | hsivonen | tries to find out what -R |
| 09:49 | <hsivonen> | does |
| 09:52 | <zcorpan_> | hsivonen: livedom.validator.nu doesn't have the bit set but runs scripts |
| 09:52 | <hsivonen> | zcorpan_: oops. thanks for noticing. |
| 09:53 | Philip` | really should have split his set of pages into much smaller chunks |
| 09:53 | <Philip`> | I just split it into 16, and it can take ~10 minutes to run one of them, so it's not very good for progress indication or for parallelism when it's only got one chunk left :-( |
| 09:57 | <hsivonen> | whoa. <a role=button> sure has generated a lot of email while I wasn't looking |
| 09:58 | <hsivonen> | when the whole thing should really have been a super-simple spec fix: allowing roles on <a> |
| 09:58 | <hsivonen> | Whoa. WONTFIX |
| 09:58 | <zcorpan_> | i think <a role=button> is like <p> </p> |
| 10:00 | <hsivonen> | Hixie: I think <a> has enough of abuse history that is should be considered sacrificed like <div> |
| 10:02 | <zcorpan_> | using <a> for a button also isn't too bad |
| 10:02 | <zcorpan_> | you get keyboard access, which is better than <span> |
| 10:02 | <zcorpan_> | and <button> is annoying to style in some browsers |
| 10:05 | <zcorpan_> | i wonder if <noscript> parsing when scripting is enabled is good enough or if pages rely on the IE way of parsing it |
| 10:06 | <hsivonen> | what's the IE way? |
| 10:06 | <zcorpan_> | dropping the tokens, iirc |
| 10:10 | jgraham | takes it that hsivonen doesn't susbscribe to the HTTP-weenie philosophy that users use the difference between links and buttons to determine safe vs unsafe operations |
| 10:11 | <hsivonen> | jgraham: users can only use the difference if the <a> element looks like a link |
| 10:11 | <hsivonen> | jgraham: if it looks like a button, it should be announced as a button by screen readers, too |
| 10:12 | <jgraham> | hsivonen: Right, so the theory is that links should never look like buttons and therefore should never have role=button |
| 10:12 | jgraham | doesn't subscribe to this philosophy |
| 10:12 | <hsivonen> | jgraham: it sucks that the accessibility bit is the only part that can be realistically caught programmatically as the author doing something bad |
| 10:13 | <hsivonen> | jgraham: but if the validator whines, the authors are just going to break accessibility. they aren't going to stop repurposing links as buttons |
| 10:13 | <jgraham> | (in particular I don't think that real users actually make the distinction that HTTP people claim that they should be making) |
| 10:13 | <Philip`> | I think that's what Steve Faulkner said |
| 10:14 | <Philip`> | and it seemed quite a reasonable argument to me |
| 10:14 | <jgraham> | (I haven't actually read any of that thread yet so I'm only saying things that have come up the previous N times this discussion has happened) |
| 10:14 | <Philip`> | People don't care if they're violating the spec, they just care if the validators complains that they are, and they will make minimal changes to stop the validator complaining |
| 10:15 | <Philip`> | s/that's what/what hsivonen said about programmatic catchability is what/ |
| 10:16 | <zcorpan_> | Philip`: indeed |
| 10:40 | <zcorpan_> | hmm, i meant "i wonder if <noscript> parsing when scripting is *dis*abled is good enough or if pages rely on the IE way of parsing it" |
| 10:42 | <Philip`> | zcorpan_: http://philip.html5.org/data/cdata-containing-self-close-with-script.txt |
| 10:43 | <zcorpan_> | Philip`: thanks! |
| 10:51 | <zcorpan_> | http://simon.html5.org/dump/cdata-containing-self-close-with-script.xml |
| 10:52 | <zcorpan_> | 884 occurrences for script |
| 10:52 | <zcorpan_> | 5 for noscript |
| 10:55 | <zcorpan_> | two of the noscript have the encoding problem |
| 10:55 | <zcorpan_> | one would show "-->" |
| 10:55 | <zcorpan_> | one works equally with or without escapedness |
| 10:56 | <zcorpan_> | and one has the <noscript><!--</noscript>FOO<noscript>--></noscript> "trick" |
| 11:01 | <zcorpan_> | which will actually start to work as a trick with the currently specified parsing rules |
| 11:05 | <zcorpan_> | hsivonen: maybe parity-IE refers to IE with dean's wf2 script |
| 11:16 | <zcorpan_> | document.write('</SCRIPT\> \n'); |
| 11:16 | <zcorpan_> | also a way to escape the end tag... |
| 11:20 | <hsivonen> | zcorpan_: could be referring to Dean's scripts, yes. dunno. |
| 11:21 | <zcorpan_> | wonder if we want to whine about people who do <script><!--d.w('<script></script\>');--></script> |
| 11:25 | <Philip`> | zcorpan_: Is it possible to detect and whine in a way that tells the user what they should do to fix the problem properly? |
| 11:26 | <Philip`> | (presumably telling them to write <\/script> or something) |
| 11:36 | <zcorpan_> | Philip`: actually writing it as <\/script> would also be invalid |
| 11:37 | <zcorpan_> | assuming i've understood the abnf correctly |
| 11:39 | <zcorpan_> | i guess the right recommendation is to not use <!-- at all |
| 11:44 | <zcorpan_> | maybe i should try to ignore the validation aspect and focus on compat first |
| 11:45 | <jgraham> | Validation is for wimps anyway |
| 11:52 | <hsivonen> | MikeSmith: I've now redeployed V.nu |
| 11:52 | <MikeSmith> | hsivonen: cool |
| 11:53 | <zcorpan_> | MikeSmith: any highlights? |
| 11:54 | <hsivonen> | MikeSmith: thanks for developing stuff to deploy |
| 11:57 | <MikeSmith> | zcorpan_: Nothing so big. I added some "Use FOO instead." suggestions to the error messages for obsolete elements, and updated the microdata stuff and content model for <caption> so that the HTML5 spec would validate |
| 11:57 | <zcorpan_> | MikeSmith: cool |
| 11:58 | <zcorpan_> | does html5 have a requirement along the lines of "conformance checkers must report this document as valid"? :) |
| 11:58 | <MikeSmith> | hsivonen: thanks for making something worthwhile that people can help develop stuff for :) |
| 12:00 | <MikeSmith> | hsivonen: btw, I think I finally made some time to work on the datatype warnings mechanism.. but will need some time from you to answer questions |
| 12:00 | <MikeSmith> | hsivonen: assuming you think it's worth pursuing |
| 12:01 | <MikeSmith> | hsivonen: first question would be, how should the messages be flagged as warnings? just with a magic substring as part of the message text? or some other flagging mechanism? |
| 12:02 | <darobin> | hey |
| 12:03 | <darobin> | is there a reason why entries in an appcache manifest must have the same scheme as the manifest itself? |
| 12:03 | <MikeSmith> | hsivonen: also, seems like we need to add a Java property name. nu.validator.servlet.warnings=1 ? or something like that? |
| 12:03 | <hsivonen> | MikeSmith: assuming that the plan is to go with the trick that Jing thinks there's an error but the UI downgrades the presentation to a warning, I think the warningness should be a flag on the exception object or a subclass of the datatype exception class |
| 12:03 | <MikeSmith> | OK |
| 12:04 | <hsivonen> | MikeSmith: the property name should probably show that it belongs to the datatype package rather than the servlet front end, but yeah, a system property is needed |
| 12:04 | <darobin> | I was hacking on something that's local, but for which I'd like remote resources to be appcached so that I can keep hacking while travelling |
| 12:04 | <darobin> | but this prevents it |
| 12:05 | <hsivonen> | darobin: my guess is that the point is to prevent the case where an evil origin pins stuff in the cache from a good origin |
| 12:05 | <darobin> | I can't seem to think of a reason why an appcache couldn't reference things from all over the place |
| 12:05 | <hsivonen> | darobin: and then the scheme restriction just falls out of that |
| 12:05 | hsivonen | knows almost nothing about app cache |
| 12:06 | <darobin> | hsivonen: well, I'd expect stuff in appcache to only be appcached for pages that point to that manifest |
| 12:06 | <darobin> | note that it's only same-scheme, it's not same-origin (that I can tell) |
| 12:06 | <darobin> | this is a bummer |
| 12:07 | <hsivonen> | ah. I know nothing about that. |
| 12:07 | <hsivonen> | http://html5.org/tools/web-apps-tracker?from=4287&to=4288 has a copy-paste error, right? |
| 12:08 | <darobin> | ah well, thanks anyway |
| 12:10 | hsivonen | finds a page that gives the YSoD in Minefield but not in Safari or Opera |
| 12:10 | <hsivonen> | yay for serving broken XML to Gecko only as XML |
| 12:10 | <zcorpan_> | hsivonen: yes, i've sent email about that |
| 12:11 | <hsivonen> | Hixie: Boris had a reason for making the <form> element hiding HTML-document-only. I don't recall what the reason was. |
| 12:12 | <MikeSmith> | darobin: I think I found the reason |
| 12:12 | <MikeSmith> | hang on, I'll get you a URL |
| 12:14 | <darobin> | ah, that'd be cool |
| 12:14 | <MikeSmith> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012689.html |
| 12:15 | <MikeSmith> | the paragraphs that begins, "I'm not sure how to work around this." |
| 12:15 | <zcorpan_> | hsivonen: it seems such forms aren't display:none in opera even in html |
| 12:15 | <darobin> | MikeSmith: you're a star, I coudn't dig anything up |
| 12:16 | <hsivonen> | zcorpan_: does Opera have other magic for ensuring the such forms don't break the table layout? |
| 12:16 | <MikeSmith> | darobin: so now you need to tell Hixie to come up with a better workaround.. |
| 12:17 | <darobin> | mmmm, right, this is really a workaround :) |
| 12:17 | <darobin> | and big workaround, I really mean big ugly dirty hack |
| 12:17 | <zcorpan_> | hsivonen: the forms end up in an anonymous <caption> box |
| 12:18 | <hsivonen> | zcorpan_: ok |
| 12:18 | <hsivonen> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=349695 |
| 12:19 | <annevk42> | darobin, appcache is supposed to be same-origin |
| 12:19 | <annevk42> | darobin, sadly the reason as to why escapes me at the moment |
| 12:20 | <MikeSmith> | hsivonen: about the build script, I think one more refinement that could be made is, for the case where the htmlparsers dir exists but doesn't have an .hg subdir (because it's the existing svn checkout), either (1) emit a message telling the user to manually move or delete the existing htmlparser subdir, and exit; or (2) have the build script move the existing htmlparser to htmlparser-svn or whatever, emit a message telling the user it's been moved, a |
| 12:20 | <MikeSmith> | nd continue with the build. |
| 12:20 | <zcorpan_> | hsivonen: but it seems that opera produces a margin because of the form |
| 12:21 | <zcorpan_> | i wonder how ie deals with it |
| 12:21 | <hsivonen> | MikeSmith: I'll change the build script |
| 12:21 | <MikeSmith> | hsivonen: OK |
| 12:24 | <zcorpan_> | oh right, ie produces a non-tree |
| 12:25 | <hsivonen> | MikeSmith: done |
| 12:25 | <MikeSmith> | cheers |
| 12:26 | <zcorpan_> | or something funny at least (the tbody is nested inside the form) |
| 12:27 | <darobin> | annevk42: mmmm, same-origin doesn't sound like a great idea for appcache |
| 12:27 | <darobin> | it pretty much makes it useless in fact |
| 12:28 | <darobin> | actually, master entries must be same origin, but not explicit entries |
| 12:28 | <annevk42> | oh ok |
| 12:28 | <annevk42> | hmm |
| 12:28 | <annevk42> | and here I thought I knew how stuff worked |
| 12:30 | <darobin> | yeah, I don't really understand either :) |
| 12:31 | <annevk42> | I think the problem you might be facing is that file: has an undefined security model |
| 12:31 | <MikeSmith> | hsivonen: "hg pull: option --rebase not recognized" |
| 12:31 | <annevk42> | You would probably be better off installing lighthttpd or some such |
| 12:31 | <hsivonen> | MikeSmith: which version of hg? |
| 12:31 | <annevk42> | lighttpd that is |
| 12:31 | <hsivonen> | maybe I should take out "--rebase" until I actually need it |
| 12:32 | <MikeSmith> | hsivonen: I've got 1.3.1 installed |
| 12:32 | <hsivonen> | MikeSmith: ok. apparently, --rebase is only recognized if you've enabled it |
| 12:32 | <hsivonen> | MikeSmith: I took it out |
| 12:32 | <MikeSmith> | OK |
| 12:33 | <hsivonen> | oh. now I need to add -u or something instead |
| 12:33 | <hsivonen> | hmm. |
| 12:33 | <MikeSmith> | hsivonen: enabled at compile time? or through a user config option? |
| 12:34 | <MikeSmith> | ha |
| 12:34 | <hsivonen> | MikeSmith: user config |
| 12:34 | <MikeSmith> | ah |
| 12:34 | <hsivonen> | I put in --update instead |
| 12:34 | <MikeSmith> | I see -- I'm reading the man page now, "Using additional features" |
| 12:36 | MikeSmith | syncs ups |
| 12:36 | <hsivonen> | http://mercurial.selenic.com/wiki/RebaseExtension |
| 12:38 | MikeSmith | takes a look |
| 12:39 | <MikeSmith> | hsivonen: do you anticipate making changes that'll require a rebase instead of just an update? |
| 12:39 | <MikeSmith> | wow.. Guha posted to public-html |
| 12:40 | <hsivonen> | I was thinking --rebase would be useful if one started using mercurial queues in the same sandbox that is use by build.py |
| 12:40 | <hsivonen> | let's cross that bridge when we get there |
| 12:41 | <MikeSmith> | sounds sane to me |
| 12:42 | <darobin> | annevk42: yeah I know that, but that defeats the point of making things simple — plus I think I'll still run into same-origin issues |
| 12:42 | <darobin> | another option is for me to set up a caching proxy locally |
| 12:46 | <hsivonen> | was there a decision about async scripts waiting / not waiting for style sheets? |
| 12:49 | <annevk42> | I think Hixie changed the spec on that front, yes |
| 12:59 | <zcorpan_> | almost all </script\> cases are document.written VBScripts |
| 12:59 | hsivonen | wonders if there's a famous VBScript tutorial with that pattern |
| 13:00 | <zcorpan_> | it seems to be boilerplate for including something for Flash |
| 13:01 | <annevk42> | wtf, ffmpeg is a disaster on Mac |
| 13:02 | annevk42 | wonders if it's because of Chrome that it keeps running in the background and never shuts down and then crashes every couple of minutes |
| 13:05 | <zcorpan_> | up to 57; i've now found the two kinds of breakage with double escape (same pages as found with the regexp search) |
| 13:06 | <zcorpan_> | the rest seem to work as intended with double escape |
| 13:08 | <zcorpan_> | the encoding problem shows up in <script> too |
| 13:09 | <zcorpan_> | var strAdBegin="<!--鐢讳腑鐢诲紑濮�->"; |
| 13:10 | <zcorpan_> | (though double escape takes care of closing the script at the right place) |
| 13:11 | <zcorpan_> | <script></script\></div></body></html> - hmm |
| 13:17 | <Philip`> | Encoding problem is annoying :-( |
| 13:17 | Philip` | ought to look into it and work out what he's doing wrong |
| 13:20 | <zcorpan_> | Philip`: the encoding of one page i checked seems right in firefox with html5.enable |
| 13:21 | <zcorpan_> | Philip`: also right when validating in v.nu |
| 13:27 | <Philip`> | zcorpan_: Yeah, I guess I might have a funny icu4j or something |
| 13:53 | <annevk42> | zcorpan_, you should fix your email clock |
| 14:06 | <zcorpan_> | annevk42: i blame opera |
| 15:19 | <deadowl> | Can I propose links to anchors cascading across viewports? |
| 15:22 | <jgraham> | Erm, you ca propose anything you like |
| 15:22 | <jgraham> | Although it isn't clear, at least to me, what you have in mind here |
| 15:22 | <deadowl> | I have a navigation: <prev | Mon: mm/dd/yy | Tue: ... | Wed | Thu | Fri | Sat | Sun | next >. I have a div using overflow:auto; to behave as a scrolling area (viewport). I was thinking that if I could have overflow:hidden for the prev/next so I could anchor different versions that would link to the same day, but of the next week. |
| 15:23 | <deadowl> | Mon/Tue/Wed acting as anchor names with links within the page, and prev/fwd acting as links to separate pages. |
| 15:25 | <deadowl> | however, that would require duplicating all of the content on the page 7 times. |
| 15:26 | <deadowl> | going to lunch. |
| 15:31 | <zcorpan_> | there are no </script\>s in http://philip.html5.org/data/script-open-in-escape.txt which either means that they are not problematic for double escape or the regexp is written in such a way to exclude the problematic pages |
| 15:32 | <zcorpan_> | i envision someone doing <script><!--d.w('<script></script\>');</script> |
| 15:34 | <zcorpan_> | it appears that pages escaping the end tag with a trailing backslash either don't use <!-- at all or have a matching --> at the end |
| 15:35 | <Philip`> | It could also mean the validator.nu parser is not matching those patterns |
| 15:36 | <zcorpan_> | the above data didn't use the v.nu parser at all |
| 15:42 | <Philip`> | Oh, right |
| 15:43 | <hsivonen> | cool. it seems the <itemref> element went away before I got around to complaining about it on the mailing list |
| 15:43 | <TabAtkins> | deadowl: I'm still not sure quite what you're getting at with the talk of "viewports", but yes, you'd need to write out the content 7 times, once for each day, if you want Mon-Sun to just be anchors into the page. Alternately, use js to update the page appropriately. |
| 15:45 | <TabAtkins> | deadowl: Oh wait, I think I get what you're saying now. If you've already clicked on Tuesday, frex, and are thus at foo.html#tuesday, then you click "next", you'd like to show bar.html#tuesday, rather than just bar.html. Right? |
| 15:46 | <zcorpan_> | i don't see any <\/script> anywhere. that seems fishy. why are there no <\/script> in the above? |
| 15:46 | <TabAtkins> | deadowl: For now, just js-update the prev/next links to contain the appropriate anchor whenever you click on one of the Mon-Sun links. This degrades acceptably. |
| 15:47 | <Dashiva> | zcorpan_: The regexp only looks for </script>? |
| 15:47 | <Dashiva> | Or well, </script |
| 15:50 | <zcorpan_> | Dashiva: http://philip.html5.org/data/script-open-in-escape.txt shouldn't exclude pages with say <script><!--d.w('<script><\/script>');</script>, right? |
| 15:51 | <Philip`> | (?i)<script[^>]*>([^<]|<(?!/script[\s/>]))*<!--([^-]|-(?!->))*<script[\s/>]([^-]|-(?!->))*</script[\s/>] |
| 15:51 | <Philip`> | Looks like it shouldn't exclude it |
| 15:52 | <Philip`> | $ echo '<script><!--d.w("<script><\/script>");</script>' | grep -P '(?i)<script[^>]*>([^<]|<(?!/script[\s/>]))*<!--([^-]|-(?!->))*<script[\s/>]([^-]|-(?!->))*</script[\s/>]' |
| 15:52 | <Philip`> | That says it matches |
| 15:55 | <zcorpan_> | ok |
| 15:57 | <zcorpan_> | i guess that's good and we can keep <\/script> and </script\> invalid inside double escape |
| 18:23 | <Tripknotix> | hi everyone |
| 18:23 | <Tripknotix> | ive got a question about html5 |
| 18:23 | <Tripknotix> | for div's with scrollbars to automatically show the last bit of content without needing a focus call |
| 18:23 | <Tripknotix> | <Tripknotix> when its added |
| 18:23 | <Tripknotix> | like how current chats are made |
| 18:24 | <webben> | Tripknotix: HTML5 doesn't have a special concept of a changing region. WAI-ARIA has live regions - but that's for passing information to assistive technologies, not for changing the visual rendering. |
| 18:25 | <Tripknotix> | know any tricks for such a thing beyond the usually, add to the bottom and focus to it |
| 18:26 | <Tripknotix> | my old setup was to add to it, focus,t hen back to the typing box to focus |
| 18:26 | <Tripknotix> | but it caused a delay when someone was typing |
| 18:26 | <Tripknotix> | in frames |
| 18:26 | <annevk2> | set scrollTop |
| 18:27 | <Tripknotix> | hows that work |
| 18:28 | <Tripknotix> | <--googling |
| 18:28 | <webben> | Tripknotix: https://developer.mozilla.org/en/DOM/element.scrollTop |
| 18:28 | <Tripknotix> | was already on that page =P |
| 18:28 | <Tripknotix> | but thank u |
| 18:29 | <zcorpan_> | Tripknotix: or scrollIntoView() |
| 18:30 | <Tripknotix> | that first one is interesting, i dont understand what it would be used for |
| 18:30 | <Tripknotix> | it jut sets a number |
| 18:31 | <Tripknotix> | scroll into view sounds very interesting |
| 18:32 | <Tripknotix> | the only issue i see is |
| 18:32 | <Tripknotix> | actually |
| 18:32 | <Tripknotix> | i dont see an issue |
| 18:32 | <Tripknotix> | heres another quesiton |
| 18:32 | <Tripknotix> | would it take focus off of another frame? if the user is typing in "frames" |
| 18:32 | <Tripknotix> | ? |
| 18:32 | <Tripknotix> | i'd understand if so, but it would be great if it didnt |
| 18:33 | <zcorpan_> | i think it'd just scroll, but haven't tested |
| 18:58 | <gsnedders|work> | What does this[xxx] do? |
| 18:58 | <gsnedders|work> | (in Javascript) |
| 18:59 | <inimino> | gsnedders|work: it's property access |
| 18:59 | <zcorpan_> | xxx gets toString()ed and then does a property lookup on this, or something like that |
| 18:59 | <gsnedders|work> | And the properties on the this object are variables in the current scope? |
| 19:00 | <gsnedders|work> | (and other things bound to identifiers like functions) |
| 19:00 | <inimino> | no |
| 19:00 | <inimino> | they are the properties of 'this', the value of which depends on context |
| 19:00 | <JoePeck> | gsnedders|work: it is "bracket notation" => https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Operators/Member_Operators |
| 19:01 | gsnedders|work | grumbles at how much he hates this |
| 19:01 | <zcorpan_> | variables in the global scope become properties on the window, but variables scoped to functions don't become properties of the function, iirc |
| 19:01 | <gsnedders|work> | JoePeck: Yeah, right, I know that much |
| 19:23 | <jgraham> | gsnedders|work: Did you work it out yet? |
| 19:23 | <gsnedders|work> | jgraham: No, but I've basically given up. |
| 19:23 | <gsnedders|work> | jgraham: (for today) |
| 19:24 | <gsnedders|work> | jgraham: I'll ask you tomorrow |
| 19:26 | <jgraham> | gsnedders|work: Good (that you gave up for today) |
| 19:26 | <jgraham> | Go sleep or something |
| 19:26 | <gsnedders|work> | I've done little but that all day :) |
| 19:27 | <jgraham> | Yeah well you're ill :) |
| 19:28 | <gsnedders|work> | No worse than normal, now |
| 19:30 | <jgraham> | Hmm OK. |
| 19:30 | <jgraham> | As long as you don't make me sick :) |
| 19:30 | <gsnedders|work> | You survived over the seminar, so I guess you will |
| 19:35 | jgraham | hopes the sentence being cut off wasn't indicative of gsnedders|work suddenly dying |
| 19:35 | <Philip`> | Suddenly dying onto his enter key? |
| 19:38 | <jgraham> | Philip`: Could happen |
| 19:39 | <jgraham> | othermaciej_: btw the proposal to use vendor-prefixed attributes for user-agent experimental features seems good to me |
| 19:41 | <othermaciej_> | jgraham: I'm not sure I'd go so far as calling it a proposal, but it does seem sensible to me in light of how CSS experimental properties work |
| 21:22 | <annevk> | is anyone planning on writing a proposal to maintain the Microdata status quo? |
| 21:23 | <annevk> | also, do I understand it correctly that for every issue that opposes the status quo those who like the status quo need to write a proposal to keep it that way? |
| 21:24 | <annevk> | I somehow missed that |
| 21:26 | <Dashiva> | Well, if the change proposal is rejected, you don't have to do anything |
| 21:26 | <Dashiva> | But that's a long bet to take |
| 22:33 | <JonathanNeal> | Is there a downable version of outliner? |
| 23:21 | <hober> | annevk: my understanding is that microdata is a one-off re: your question about status quo proposals |