| 06:35 | <yod> | me lost his tunnel - cuappy network |
| 06:37 | <yod> | agh, and wrong channel - xchat-- |
| 08:22 | <Lachy> | hmm. I don't like the idea of allowing CURIEs for aria roles. |
| 08:24 | <othermaciej> | are they CURIEs or QNames? |
| 08:25 | <othermaciej> | or are you allowed to mix both in the same attribute? (shudder) |
| 08:25 | <Lachy> | IIRC, CURIEs are slightly more complicated forms of qnames |
| 08:26 | <Lachy> | I don't know, I haven't finished reading simon's aria-proposal yet |
| 08:28 | <Lachy> | e.g. a curie could be written like role="foo:bar" or role="[foo:bar]". |
| 08:28 | <Lachy> | yet the processing requirements in the proposal don't seem to deal with the square brackets at all |
| 08:30 | <othermaciej> | my understanding is that CURIEs map to URIs, not [URI, localname] pairs |
| 08:30 | <othermaciej> | they work by concatenating the localname to the prefix URI basically |
| 08:30 | <othermaciej> | rather than producing a qualified name |
| 08:30 | <Lachy> | yeah, something like that. |
| 08:31 | <othermaciej> | which in a way is simpler, but having a mixed list of CURIEs and QNames seems like a bad idea for that very reason |
| 08:31 | <Lachy> | I think zcorpan is just misusing them and should drop them |
| 09:34 | <hsivonen> | Lachy: I don't like CURIEs either |
| 09:34 | <hsivonen> | It seems to me it went like this: |
| 09:34 | <hsivonen> | 1) URLs are invented as network resource locators. |
| 09:35 | <hsivonen> | 2) Locators are theoretically generalized into generic *identifiers* |
| 09:35 | <hsivonen> | 3) People start using them as identifiers that are not supposed to be dereferenced |
| 09:35 | <hsivonen> | 4) They are too long as identifiers |
| 09:36 | <hsivonen> | 5) People invent complex (and in the face of DOM manipulation, brittle) ways to compress them |
| 09:36 | <hsivonen> | Better fix: not using URLs as identifiers and only using them as network locators |
| 09:37 | <Lachy> | right, so it all went wrong as step 2. |
| 10:53 | <hsivonen> | are there actual implementations that support SVG 1.2 Tiny scripting via Java jars? |
| 10:54 | <hsivonen> | If I had to guess, I'd guess that scripting via ECMAScript would be a better match for Gecko/WebKit/Opera |
| 10:55 | <heycam> | hsivonen, it doesn't do 1.2 Tiny (just 1.1 full plus a couple of 1.2-isms), but Batik does support the scripting via Java jars |
| 10:57 | <hsivonen> | heycam: OK. interesting. |
| 10:57 | <heycam> | i don't know if many people use the features though |
| 10:57 | <hsivonen> | heycam: how do they handle security? that seems like a fast way to classloader hell |
| 10:57 | <heycam> | s/features/feature/ |
| 10:58 | <heycam> | i believe it has the same restrictions as that of ecmascript running in the document |
| 11:00 | <heycam> | i.e. those classes won't be able to write to the filesystem, open non-same-origin connections, etc. |
| 13:05 | <hendry> | are label elements depreciated? e.g. <label for="to" > |
| 13:05 | <zcorpan> | no |
| 13:06 | <zcorpan> | or at least i don't depreciate them :) |
| 13:06 | <hendry> | ok, I must be using them wrong http://validator.nu/?doc=http%3A%2F%2Fletter.dabase.com%2F |
| 13:06 | <zcorpan> | you mix block and inline |
| 13:07 | <hendry> | i keep doing that |
| 13:07 | <hendry> | also what's the story with size on the input tag? |
| 13:07 | <zcorpan> | wf2 says size="" is deprecated |
| 13:08 | <zcorpan> | will likely be dropped altogether when wf2 is integrated |
| 13:08 | <zcorpan> | (though personally i don't think size="" should be dropped) |
| 13:11 | <zcorpan> | (form also requires block children currently, also in html4 strict, so you need blocks around your labels) |
| 13:12 | <hendry> | thanks zcorpan |
| 13:14 | <hendry> | what's wrong with : input type="submit" |
| 13:15 | <zcorpan> | <input> is also inline |
| 13:15 | <zcorpan> | though the error message seems wrong |
| 13:15 | <zcorpan> | hsivonen: ^ |
| 13:16 | <hendry> | yeah ... |
| 13:16 | <zcorpan> | aha, hidden inputs are allowed in that context |
| 13:16 | <hendry> | safari doesn't seem to render the text in the opening/closing inputs, whilst firefox does |
| 13:16 | <zcorpan> | so the schema expects type="hidden" |
| 13:16 | <hendry> | zcorpan: very good |
| 13:18 | <zcorpan> | hendry: you have a newline at the beginning of the value="" |
| 13:18 | <hendry> | is there something in WF2 I wonder, which is supposed to clear a form. For example test says "Firstname Lastname", and when editing that input it's cleared |
| 13:19 | <zcorpan> | hendry: though since it works in other browsers it's probably a bug in safari |
| 13:19 | <hendry> | oh yes |
| 13:19 | <zcorpan> | hendry: that would be placeholder="", not in html5 yet |
| 13:20 | <hendry> | oh right |
| 13:20 | <hendry> | I guess I need some JS in there |
| 13:20 | <zcorpan> | http://simon.html5.org/sandbox/js/placeholder.js |
| 13:21 | <hendry> | i thought you could do something like <input>what value would be</input> |
| 13:21 | <hendry> | looks like you can't |
| 13:22 | <zcorpan> | no, <input> is a void element |
| 13:23 | <hendry> | thanks again zcorpan |
| 13:26 | <zcorpan> | welcome |
| 13:28 | <hsivonen> | zcorpan: hendry fixed the page before I had a chance to check the message |
| 13:28 | <hsivonen> | zcorpan: however, my crystal ball tells me the message is correct but for a non-obvious reason |
| 13:28 | <hendry> | hsivonen: i'll unfix it one mo |
| 13:28 | <hsivonen> | zcorpan: <input type='hidden'> is block |
| 13:28 | <hendry> | how come placeholder only works on webkit? http://simon.html5.org/sandbox/js/placeholder-demo.htm |
| 13:29 | <zcorpan> | hsivonen: yes, i figured |
| 13:29 | <hendry> | hsivonen: http://validator.nu/?doc=http%3A%2F%2Fletter.dabase.com%2F |
| 13:29 | <zcorpan> | hendry: because they invented it and no-one else has copied it yet? |
| 13:30 | <hsivonen> | hendry: yeah, the error is correct (type=hidden would work) but unintuitive |
| 13:31 | <zcorpan> | hendry: the script should make it work in other browsers, but rely on some features that are not widely implemented |
| 13:31 | <zcorpan> | s/rely/it relies/ |
| 13:31 | <zcorpan> | such as the DOMFocusIn event |
| 13:32 | <zcorpan> | should work in opera 9.5 |
| 13:32 | <hendry> | damn, my backspace in MacOSX Terminal is misbehaving |
| 13:33 | <hsivonen> | hendry: when did you switch to non-DFSG software? |
| 13:34 | <hendry> | hsivonen: at work I use MacOSX :) |
| 13:34 | <hendry> | zcorpan: how does placeholder and textarea supposed to work? http://dabase.com/placeholder.html |
| 13:35 | <hendry> | it's just for input I think (looking at the JS) |
| 13:35 | <zcorpan> | hendry: placeholder for textarea is not implemented in webkit |
| 13:37 | <hsivonen> | zcorpan: does my name=''/usemap='' suggestion make sense in your opinion? |
| 13:38 | <hsivonen> | (formulating a researched opinion was tedious) |
| 13:39 | <hendry> | i just put a reset input on letter.dabase.com. Amazed that it doesn't actually clear the forms. It puts them how they were before |
| 13:39 | <hsivonen> | reset suck |
| 13:39 | <hsivonen> | s |
| 13:47 | <zcorpan> | hsivonen: yes, i think it makes sense. it's pretty much what i suggested, also |
| 13:50 | <hsivonen> | zcorpan: uh, right. so it is. :-) |
| 16:52 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3Ea-%C3%85%20{border%3Asolid}a-%C3%A5%20{color%3Ablue}%3C%2Fstyle%3E%3Cbody%3E%3Ca-%C3%A5%3Ea%3C%2Fa-%C3%85%3Eb |
| 16:53 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cstyle%3Ea[%C3%85]%20{border%3Asolid}a[%C3%A5]%20{color%3Ablue}%3C%2Fstyle%3E%3Cbody%3E%3Ca%20%C3%A5%3Ea%3Ca%20%C3%85%3Eb |
| 16:55 | <zcorpan> | it seems browsers differ from what html5 says for those |
| 17:16 | <jacobolus> | zcorpan: the behavior for those differs in webkit/gecko for me |
| 17:18 | <jacobolus> | that is, gecko sees </a-Å> as a closing tag for <a-å>, but webkit does not |
| 17:27 | <zcorpan> | jacobolus: indeed; webkit is per html5 |
| 17:28 | <jacobolus> | so were you just pointing that out? or suggesting the spec be to gecko's behavior, or… ? |
| 17:28 | <zcorpan> | the former |
| 17:31 | <zcorpan> | though html5 also needs to define what the case sensitivity is for elements and attributes wrt selectors |
| 17:31 | <zcorpan> | ascii-case insensitive makes sense, but doesn't match browsers |
| 17:32 | <zcorpan> | or it matches opera, actually |
| 18:13 | <zcorpan> | http://simon.html5.org/tools/js/designmode-viewer/ -- create a list and press "indent" |
| 18:13 | <zcorpan> | all browsers nest lists directly without an <li> in between |
| 21:29 | <mpt> | kingryan! |
| 21:30 | <mpt> | A few days ago you were wondering whether anyone uses "*" in URLs |
| 21:30 | <kingryan> | I was? |
| 21:30 | <mpt> | Darn, I've been saving up an example for you all this time and now you don't even remember :-) |
| 21:31 | <kingryan> | were we talking about comments in manifests? |
| 21:31 | <mpt> | One moment, I'll find out |
| 21:33 | <mpt> | Oct 04 12:47:45 <Hixie> blimey URIs use a lot of symbols. ok if we're to allow comments at end of lines we have to have a comment delimited that isn't one of + - . : / @ _ ~ % ! $ & ' ( ) * , ; = [ ] ? # |
| 21:33 | <kingryan> | right |
| 21:33 | <kingryan> | * can't be used b/c its part of URL syntax |
| 21:33 | <mpt> | ... |
| 21:34 | <mpt> | Oct 04 12:55:09 <kingryan> what about '*' ? |
| 21:34 | <mpt> | ... |
| 21:34 | <mpt> | Oct 04 12:55:45 * kingryan has no idea where * is used in URLs |
| 21:34 | <mpt> | There we go |
| 21:34 | <mpt> | anyway |
| 21:34 | <mpt> | One popular example of * in URLs is the Wayback Machine. |
| 21:34 | <kingryan> | ah yeah, I think I've seen that |
| 21:34 | <mpt> | e.g. <http://web.archive/org/*/http://www.whatwg.org/> (here, "*" means "show me all the versions you have") |
| 21:43 | jgraham | just added some tests that ruby html5lib ought to fail |
| 21:44 | <kingryan> | jgraham: I take that as a challenge :) |
| 21:44 | <jgraham> | specifically I just added logic to the python side to assume utf-8 when utf-16 is found in the meta pre-parse algorithm |
| 21:44 | <kingryan> | is that in the spec? |
| 21:44 | <jgraham> | this is what hsivonen seems to do |
| 21:45 | <jgraham> | Since it's impossible for any file that is actually utf-16 encoded to be detected by the pre-parse it doesn't seem unreasonable |
| 21:45 | <jgraham> | but it's not in the spec yet |
| 21:45 | <kingryan> | yeah |
| 21:45 | <jgraham> | We were failing on real files because of this |
| 21:46 | <kingryan> | I see |
| 21:46 | <kingryan> | the python tests are failing for me now |
| 21:47 | <jgraham> | Oh. |
| 21:47 | <kingryan> | LookupError: unknown error handler name ' replace' |
| 21:47 | <kingryan> | from |
| 21:47 | <kingryan> | File "/Users/ryan/projects/html5lib/python/tests/test_encoding.py", line 18, in encodingTest |
| 21:47 | <kingryan> | stream = inputstream.HTMLInputStream(data,chardet=False) |
| 21:47 | <kingryan> | File "/Users/ryan/projects/html5lib/python/src/html5lib/inputstream.py", line 61, in __init__ |
| 21:47 | <kingryan> | ' replace') |
| 21:48 | <kingryan> | looks like the space before 'replace' might be a problem |
| 21:49 | <jgraham> | hmm wfm |
| 21:49 | <kingryan> | fwiw, I'm running it via 'sh runtests.sh' |
| 21:50 | <hsivonen> | the sniffing part of the spec changed after I did my impl |
| 21:51 | <jgraham> | OK, so I removed the whitespace |
| 21:53 | <jgraham> | hsivonen: I don't think it covers the case of <meta charset="UTF-16"> in the current version |
| 21:53 | <jgraham> | assuming the <meta> is detected by the pre-parser |
| 21:53 | <jgraham> | it works if the <meta> is not in the first 512 bytes though |
| 21:55 | <jgraham> | (the spec that is) |
| 21:59 | <hsivonen> | jgraham: IIRC, I did with UTF-16 what someone from Apple said WebKit does |
| 22:00 | <hsivonen> | jgraham: IIRC, UTF-16 in meta needs to be taken to mean UTF-8 for Web compat |
| 22:47 | <jgraham> | hsivonen: Yeah, I think I remember othermaciej saying that; which is also what the comment in your source says :) |
| 22:54 | <kingryan> | ruby version of htm5lib updated to do utf-8 instead of utf-16 for meta@charset |
| 22:56 | <jgraham> | :) |
| 22:58 | Philip` | discovers that gitweb outputs actual XHTML |
| 22:58 | <Philip`> | though I only discovered that because I got a well-formedness error while trying to use it |
| 23:00 | <kingryan> | Philip`: is it really xhtml then ? |
| 23:00 | <kingryan> | :) |