| 02:19 | <Hixie> | it seems people have discovered that you can use my data: URI kitchen to save things like PDFs and such for offline viewing on iPhones |
| 02:19 | <Hixie> | and they are now uploading multi-megabyte PDFs and the like to my server |
| 05:06 | <gavin_> | heh |
| 07:25 | <hsivonen> | "captive portal"? |
| 07:25 | <Hixie> | router that returns 307 for all uris, e.g. used for wireless networks to get payment information |
| 07:27 | <hsivonen> | ah |
| 07:27 | <hsivonen> | those are evil |
| 07:28 | <Hixie> | but it is very common to hit these when in an offline situation |
| 07:29 | <Hixie> | so we have to handle them |
| 07:30 | <jruderman> | as long as we don't require letting them MITM TLS connections |
| 07:31 | <hsivonen> | Hixie: yes, I realize that they are common even if not popular |
| 07:32 | <hsivonen> | I particularly dislike the ones that don't even want my money but that want me the click through a disclaimer an over-eager lawyer wrote |
| 07:33 | <hsivonen> | jruderman: It seems to me that WLAN authorization purchases are finally a use case for CA-approved certs. |
| 07:34 | <hsivonen> | I wonder how many bogus access points there are around Europe pretending to be Orange access points but phishing for credit card numbers |
| 07:34 | <jruderman> | hsivonen: what do you mean? |
| 07:34 | <jruderman> | (about CA-approved certs) |
| 07:35 | <hsivonen> | jruderman: certs signed by CAs that the browser has root certs for in advance |
| 07:36 | <hsivonen> | jruderman: that is, a picking a random access point in a foreign town is much more likely to direct you to a phishing node than the DNS of your wired broadband provider |
| 07:37 | <hsivonen> | though I suppose a proper phishing node could forge IP addresses on its fake network |
| 07:37 | <hsivonen> | and just grab a cert from a real site |
| 07:38 | <jruderman> | oh, you're saying that wireless (not just wireless that charges) is a good reason for using CAs rather than SSH-style authentication |
| 07:40 | <hsivonen> | jruderman: I was saying that certs are useful for authenticating the wireless charging entry points |
| 07:41 | <hsivonen> | (scratch what I said about cert stealing above. of course it doesn't give the stealer the private key) |
| 07:42 | <jruderman> | because if it weren't for wireless networks that charged, you could just wait until you get home to do your credit card purchases? |
| 07:44 | <hsivonen> | jruderman: no that's not what I meant. just that the payment portal seems like lower-hanging fruit to forge than a random site on the net and hoping that someone on the phishing AP makes a purhase on the random site |
| 07:44 | <jruderman> | ok |
| 07:47 | <hsivonen> | on a different note, is it ever uttered out loud which concrete browsers are expected to do the mobile profile stuff |
| 07:49 | <Hixie> | i never understood that either |
| 07:53 | <othermaciej> | I was going to comment on the CSS Mobile Profile on the basis that such a thing is (a) useless and (b) harmful |
| 07:53 | <othermaciej> | but it seems like wasted breath |
| 08:09 | <hsivonen> | Hixie: I think it is a bit weird that the party line is that people are expected to continue to use text/html, but HTML 5 contains many XHTML/DOM-only content model expansions |
| 08:37 | <hsivonen> | Hixie: an extra ">": The cite DOM attribute must reflect the element's >cite content attribute. |
| 13:29 | <krijnh> | \o/ |
| 13:32 | <krijn> | So, it appears, cables should be connected |
| 13:32 | <krijn> | That's something new |
| 13:32 | <OmegaJunior> | lol |
| 13:33 | <OmegaJunior> | In case of wires: connect. In case of wireless: don't. |
| 13:40 | <krijnh> | Can't agree more :) |
| 13:47 | gsnedders | got 46/52 in the computing test. only two of the lost marks were due to the actual "correct" answers being wrong. |
| 13:49 | <OmegaJunior> | Yes, what is correct according to text books and exams can differ greatly from what is correct according to parsers, compilers and browsers, which in turn differs from what is correct according to the end user. |
| 13:49 | <krijn> | That is correct |
| 13:50 | <hendry> | so <br> tag is a 'void element'. What is a <p> called? |
| 13:51 | <gsnedders> | OmegaJunior: not just according to parsers, compilers, and browsers but also specifications |
| 13:51 | <OmegaJunior> | Phrase element? |
| 13:51 | <OmegaJunior> | For a test, that's a bad situation. |
| 13:52 | <OmegaJunior> | Depends on the transparancy of the spec, I'm sure. |
| 13:54 | <hsivonen> | hendry: <p> is a start tag |
| 13:54 | <gsnedders> | OmegaJunior: US-ASCII (whatever that is — I assume ANSI X3.4-1968) is 8-bit, and Unicode is 16-bit (despite unicode not being an encoding form) |
| 13:55 | <OmegaJunior> | Isn't UTF-8 an 8-bit form of Unicode? |
| 13:56 | <OmegaJunior> | I guess you'd recognise it by it being called 'UTF-8' and not Unicode... |
| 13:56 | <gsnedders> | no, UTF-8 encodes codepoints between one and five 8-bit bytes. |
| 13:56 | zcorpan | thought it was 1-6 bytes |
| 13:56 | <gsnedders> | s/five/four/ |
| 13:57 | <gsnedders> | zcorpan: it was originally six, then changed to limit to 0x10FFFF (which can be done in four bytes) |
| 13:57 | <gsnedders> | UTF-16 is two/four bytes. |
| 13:57 | <hendry> | hsivonen: though <p> are used like 'void element's a lot |
| 13:57 | <gsnedders> | UTF-32 is four bytes. |
| 13:57 | <hendry> | hsivonen: and start tag implies it should be ended? little confused on the terminology |
| 13:58 | <gsnedders> | zcorpan: <http://tools.ietf.org/html/rfc3629#section-12>; |
| 13:58 | <zcorpan> | <br> is also a start tag |
| 13:58 | <hsivonen> | hendry: a void element is an element that cannot have content in the text/html serialization and doesn't have an end tag |
| 13:58 | <gsnedders> | zcorpan: as you're limited to 10FFFF at the highest, and non-shortest forms are invalid, you cannot have more than four byte sequences |
| 13:58 | <zcorpan> | gsnedders: ah, ok |
| 13:58 | <hsivonen> | hendry: omitting </p> doesn't make <p> void |
| 14:02 | <zcorpan> | in the parser, br and p are both categorized as "special". on the text/html syntax authoring side, br is categorized as "void element" and p is a "normal element" |
| 14:02 | <hsivonen> | I wonder what the back and forward compat story of the source element is as far as voidness goes... |
| 14:02 | <hsivonen> | oh, right </br> is weird when it comes to parsing |
| 14:03 | <zcorpan> | </p> also :) |
| 14:05 | <gsnedders> | what does </p> do? |
| 14:07 | <OmegaJunior> | It signals the end of a p element |
| 14:07 | <hendry> | hsivonen: so when reading the spec. to distinguish between void element and say a tag, I should be looking at the "content model" |
| 14:08 | <hsivonen> | hendry: no |
| 14:08 | <hendry> | some things seem to have to be closed, like when I was just playing with <object>, whilst others not so. I guess it's browser thing. |
| 14:08 | <hsivonen> | hendry: "void" is a text/html serialization/parsing concept |
| 14:08 | <hsivonen> | hendry: empty content model is a document tree-level concept |
| 14:08 | <hsivonen> | hendry: it isn't safe to infer a relationship |
| 14:09 | <hendry> | hsivonen: so how do i read the spec for "serialization/parsing concept"? |
| 14:09 | <hsivonen> | hendry: to make things worse, the parsing stuff for new elements that are supposed to be empty hasn't been nailed down |
| 14:09 | <hsivonen> | hendry: the parsing and writing html sections |
| 14:11 | <hendry> | hsivonen: thanks for the clarification(s) |
| 14:11 | <zcorpan> | gsnedders: if there's no p in scope, </p> is the same as <p></p> |
| 14:11 | <gsnedders> | zcorpan: thanks |
| 14:12 | <hsivonen> | hendry: I think it would be useful for the element definition sections to have text/html-specific serialization notes, because people expect to find the advice there (but don't currently) |
| 14:13 | <zcorpan> | Lachy: http://html5.lachy.id.au/ has been Service Unavailable for me for a while now :( |
| 14:13 | <Lachy> | yeah, I know. |
| 14:13 | <Lachy> | I can't fix it till my computer arrives from Australia |
| 14:13 | <zcorpan> | ok |
| 14:14 | <Lachy> | and that's taken longer than expected |
| 14:14 | <gsnedders> | Lachy: stop moving so far :P |
| 14:14 | <Lachy> | it should arrive next week |
| 14:14 | <hendry> | is there a part in html5 that distinguishes between relative URIs? i noticed that HTML4 does |
| 14:14 | <zcorpan> | distinguishes between relative URIs and what? |
| 14:15 | <zcorpan> | relative IRIs? absolute URIs? elephants? :) |
| 14:17 | <OmegaJunior> | They're all URI's... should it matter to the html5-spec whether they're relative or absolute? |
| 14:18 | <hsivonen> | hendry: there's one place in WF2 that requires an absolute URI |
| 14:18 | <OmegaJunior> | Ah. It does matter. |
| 14:18 | <hsivonen> | hendry: value attribute on input type='url' |
| 14:19 | <hsivonen> | hendry: profile is gone at least for now |
| 14:21 | <hendry> | sorry i was called away for a moment zcorpan :) |
| 14:21 | <OmegaJunior> | hsivonen, why does input type='url' require absolute uri's? |
| 14:22 | <hsivonen> | OmegaJunior: I guess entering relative URIs into a form generally does not make sense |
| 14:22 | <hsivonen> | OmegaJunior: since you want the value to work without a base URI |
| 14:23 | <gsnedders> | if you allow relative URIs, is it relative to the page at which the form is on, or relative to the page that receives the form? |
| 14:27 | <OmegaJunior> | Makes sense. |
| 14:27 | <OmegaJunior> | Thanks! |
| 14:38 | <hendry> | i was also thinking of forms today. reset and password |
| 14:38 | <hendry> | is "reset" actually useful? :) |
| 14:38 | <hendry> | and do passwords need to be obfuscated by ***** |
| 14:39 | <hsivonen> | hendry: no and yes |
| 14:40 | <hendry> | they need to be obfuscated you say? does it say in the spec? I don't think so |
| 14:41 | <hendry> | i find the obfuscation really painful when typing in wireless keys with my shiny ipod touch |
| 14:41 | <OmegaJunior> | Personally I think such obfuscation silly. The password will still show up in the source if echoed back. |
| 14:42 | <hsivonen> | hendry: reset isn't useful but obfuscation of passwords is when you are not guaranteed to be alone |
| 14:43 | <hendry> | UA should have an option to specific, i'm alone. not in a public place. :) |
| 14:43 | <hsivonen> | hendry: Nokia UIs (both Maemo and S60 briefly give visual feedback for each character before obfuscating it) |
| 14:43 | <hsivonen> | hmm. misplaced ) |
| 14:43 | <OmegaJunior> | So does the Motorola Razr |
| 14:44 | <hendry> | OmegaJunior: so you could perhaps write a piece of JS to echo it back without obfuscation/ |
| 14:44 | <OmegaJunior> | Yeah, or just use an input type='text' |
| 14:44 | <hsivonen> | OmegaJunior: it isn't about being plain text in the source |
| 14:46 | <OmegaJunior> | Which makes it even more silly. |
| 14:46 | <hsivonen> | OmegaJunior: what's silly about people looking over your shoulder? |
| 14:46 | <OmegaJunior> | It's silly to type in sensitive info when they are. Ever seen someone who can read your typing off of your finger movements? It's quite easy. |
| 14:47 | <hsivonen> | OmegaJunior: use Dvorak :-) |
| 14:47 | <OmegaJunior> | :D |
| 14:48 | <hendry> | also i think some keypads have different frequences depdending on what you type |
| 14:49 | <hendry> | damn, I can't type at all. Getting used to my new Das Keyboard |
| 15:12 | <hsivonen> | validator.nu now supports dialog and various other relatively recent language changes except data templates |
| 15:13 | <hsivonen> | I guess now is the time to cut the RNG in half and move interactive element exclusions to schematron |
| 15:31 | <hsivonen> | whoa are there really only 3 non-form interactive elements: a, datagrid and details |
| 15:31 | <hsivonen> | or am I misgrepping? |
| 15:33 | <OmegaJunior> | Aren't audio and video elements considered interactive? The spec does require a level of interaction. |
| 15:36 | <hsivonen> | OmegaJunior: they are not |
| 15:36 | <OmegaJunior> | OK. |
| 15:36 | zcorpan | would expect <area> to also be interactive |
| 15:37 | <hsivonen> | zcorpan: are you going to send email? |
| 15:37 | <zcorpan> | i'm not sure i understand what the "interactive" category is for, exactly |
| 15:37 | <zcorpan> | is it only for the content model? |
| 15:39 | <hsivonen> | OmegaJunior: email sent about the interactiveness of video/audio |
| 15:39 | <hsivonen> | zcorpan: the idea is to ban nesting of intrinsically clickable elements |
| 15:40 | <zcorpan> | seems weird that <details> is interactive, then; it should be ok to have links in a <details>, no? (not in the <legend>, perhaps) |
| 15:40 | <hsivonen> | zcorpan: I just sent email about that. :-) |
| 15:40 | <zcorpan> | k |
| 15:41 | <OmegaJunior> | Not received yet |
| 15:41 | <OmegaJunior> | ;) |
| 15:41 | <hsivonen> | OmegaJunior: I sent it to public-html |
| 15:41 | <zcorpan> | perhaps the Big Issue under <datagrid> also applies to <details> |
| 15:42 | <hsivonen> | how do I negate [@foo] in XPath? |
| 15:42 | <OmegaJunior> | hsivonen, I don't think I subscribed to that list |
| 15:43 | <OmegaJunior> | [~@foo]? |
| 15:43 | <hsivonen> | ~ not found in teh XPath spec |
| 15:43 | <zcorpan> | not([@foo]) ? |
| 15:44 | <OmegaJunior> | Hrm. |
| 15:44 | <OmegaJunior> | Let me look. |
| 15:45 | <hsivonen> | I want to select input elements but not input type=hidden |
| 15:46 | <hsivonen> | zcorpan: h:input[not(@type="hidden")] might be it |
| 15:47 | <OmegaJunior> | You should be able to use ~ or !... but I'm not seeing any examples. I'm looking further. |
| 15:53 | <zcorpan> | hsivonen: yeah, that seems to work |
| 15:53 | <zcorpan> | h:input[@type!='hidden'] also |
| 15:53 | <OmegaJunior> | And I learn something new: no ! operator as a shorthand for not(). |
| 15:54 | <zcorpan> | at least != works in opera |
| 15:55 | <hsivonen> | zcorpan: thanks |
| 15:56 | <zcorpan> | perhaps <img usemap> should be classified as interactive |
| 15:56 | <zcorpan> | rather than <area> |
| 15:56 | <hsivonen> | zcorpan: are you going to send email or should I? |
| 15:57 | <zcorpan> | i can do it |
| 15:57 | <hsivonen> | thanks |
| 16:03 | <zcorpan> | wonder if i should drop the "detailed review" thing :) |
| 16:15 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ca%20href%3D%3FFollowed%3E%3Cmap%20name%3Dmap%3E%3Carea%20shape%3Drect%20coords%3D0%2C0%2C200%2C100%3E%3C%2Fmap%3E%3C%2Fa%3E%0D%0A%3Cimg%20usemap%3D%23map%20src%3Dimage%3E |
| 16:15 | <Philip`> | At least in Opera, click events propagate outwards from the <area> |
| 16:16 | <Philip`> | but I don't know if that's relevant to its interactivity |
| 16:18 | <hsivonen> | Philip`: interactivity is a non-scripted document conformance concept only |
| 16:19 | <zcorpan> | hmm, not sure if click events should be dispatched when interacting with the browser's native UI of <video> |
| 16:40 | <hsivonen> | I just landed and deployed a big refactoring that moved interactive element nesting issues from RELAX NG to Schematron. Unit tests still pass, but please let me know if I broke something. |
| 16:41 | <hsivonen> | error messages for interactive element nesting violations should be *much* better now |
| 16:46 | <OmegaJunior> | Doesn't seem to raise any errors on one of my testing pages... though that was a relatively easy page. I'll whip up something more elaborate. |
| 17:22 | <gsnedders> | Lachy: didn't anyone tell you? Norway is more expensive than even here. |
| 19:10 | <Hixie_> | hsivonen: the party line was established after the extensions, in mayn cases |
| 19:10 | <Hixie_> | hsivonen: also note that the attribute stuff in the spec is the way it is (inconsistent) because at one point i decided to give up describing the optional/required constraints in the summaru |
| 19:35 | <kingryan> | Hixie_: the twitter message link to the revision seems to be working great. thanks |
| 19:35 | <Hixie_> | sweet |
| 19:36 | <Hixie_> | i had to adapt your code a bit |
| 19:36 | <kingryan> | of course |
| 19:36 | <Hixie_> | but i'm glad it's working |
| 19:37 | <kingryan> | it was hard for me to test w/out access to the repositories |
| 21:10 | <hsivonen> | Hixie_: do you intend to scale back the content model expansions now that the party line has been established? |
| 21:11 | <hsivonen> | Hixie_: I was hoping I could mine the green-background element summaries for UI messages |
| 21:11 | <Hixie_> | to be honest i really don't know |
| 21:11 | <Hixie_> | that part of the spec is a mess right now |
| 21:11 | <Hixie_> | i haven't focused on semantics for a while |
| 21:13 | <hsivonen> | ok. I try to continue to put the nonHTMLizable switches in the right places |
| 21:13 | <Hixie_> | i don't understand why this fails: http://cgi.w3.org/member-bin/process.cgi?method=url&url=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fsource-w3c&output=html |
| 21:14 | <hsivonen> | but ATM, I can only infer those places from the parsing algorithm. obviously, authors won't do that but will require more obvious docs. |
| 21:14 | <Hixie_> | for sure |
| 21:17 | <hsivonen> | I wonder how many people would actually care if I combined the xml:id Processor and the XHTML id Processor |
| 21:17 | <hsivonen> | (in some cases, duplicate ID errors would fire for xml:id-wise wrong reasons) |
| 21:19 | <hsivonen> | also, I wonder if I could get away with assigning IDness to all no-namespace attributes called id regardless of the namespace of the element... |
| 21:27 | <Hixie_> | hsivonen: question for you |
| 21:27 | <Hixie_> | hsivonen: regarding the conformance of manifests |
| 21:28 | <Hixie_> | in section "4.6.3.1. Writing cache manifests" i have conformance requirements for manifests |
| 21:28 | <Hixie_> | including: Manifests must specify all the URIs that are to be cached. |
| 21:28 | <Hixie_> | but it was pointed out that in fact, some URIs that are to be cached -- like the application document that refers to the manifest in the first place -- get cached even if not explicitly listed |
| 21:29 | <Hixie_> | and thus the conformance criteria is confusing, if not outright illadvised |
| 21:29 | <Hixie_> | do you have any advice on the matter? |
| 21:31 | <hsivonen> | Hixie_: I think it is at minimum confusing |
| 21:33 | <hsivonen> | I'm trying to come up with a better wording, but I don't know manifests well enough yet |
| 21:34 | <Hixie_> | i'm not really even sure what we should asy |
| 21:34 | <Hixie_> | say |
| 21:34 | <Hixie_> | maybe it's a useless conformance criteria |
| 21:34 | <Hixie_> | it's not like it can be tested |
| 21:35 | <hsivonen> | Hixie_: is there an easy list of things that get cached implicitly? |
| 21:35 | <Hixie_> | 1. html or xhtml files that have a manifest="" attribute on their root element |
| 21:35 | <hsivonen> | Hixie_: Authors must list the URIs they want cached in the manifest, except [short list]. |
| 21:35 | <Hixie_> | 2. things that get automatically cached from matching the caching namespaces |
| 21:36 | <Hixie_> | i think i might just drop them |
| 21:36 | <Hixie_> | it seems weird to say that an author must do what he wants to do |
| 21:37 | <hsivonen> | yes |
| 21:38 | <hsivonen> | I guess you could make a non-testable or hard-to-test requirement that authors must list the URIs that don't get cached implicitly and that need to be cached in order for the app to work |
| 21:38 | <hsivonen> | but perhaps it is just better to state the function of the list |
| 21:38 | <Hixie_> | yeah |
| 21:38 | <hsivonen> | instead of making non-testable requirements about what to put on the list |
| 21:40 | <hsivonen> | I'm going to try to combine an xml:id processor, a non-spec-based IDness assigner and ID uniqueness checking in one class |
| 21:40 | <hsivonen> | I guess that's the way to find out if the market will accept such a rigged xml:id processor |
| 21:41 | <Hixie_> | why would it not? |
| 21:41 | <hsivonen> | Hixie_: theoretically, the xml:id processor should live between the XML Processor and the XHTML layer |
| 21:42 | <hsivonen> | Hixie_: so that xml:id Errors don't depend on the XHTML layer |
| 21:42 | <Hixie_> | i see |
| 21:42 | <hsivonen> | Hixie_: if they are fused, the operation will be interleaved and you can't tell whether a duplicate ID error should be flagged an xml:id error or an XHTML id error |
| 21:43 | <hsivonen> | the way around it is not to tell the user which errors are xml:id errors :-) |
| 21:44 | <othermaciej> | it sure would be nice if xml:id was just named id |
| 21:44 | <hsivonen> | othermaciej: I intend to implement IDness assigment to id as see if people yell at me |
| 21:44 | <hsivonen> | I expect to get away with it |
| 21:44 | <othermaciej> | if you advertise that fact in the right circles they might |
| 21:46 | <othermaciej> | probably not in actual use |
| 21:46 | <Hixie_> | in actual use you're unlikely to come across any non-html anything... |
| 21:46 | <hsivonen> | I'd expect people to prefer XPath id() to *work* in actual use :-) |
| 21:47 | gsnedders | still hasn't got his head around XPath at all |
| 21:47 | <othermaciej> | I guess what I'm saying is, I don't know of a markup language with a non-ID attribute named "id" |
| 21:47 | <hsivonen> | I don't know one, either |
| 21:48 | gsnedders | could do the assholish thing of creating one, just to prove othermaciej and hsivonen wrong |
| 21:48 | <othermaciej> | gsnedders: I think there is an implicit ground rule for such claims of "no toy examples just to prove it's possible" |
| 21:48 | <gsnedders> | othermaciej: of course, it just means I have to work harder to get it actually used :P |
| 21:52 | <Hixie_> | wow, times have changed |
| 21:52 | <Hixie_> | few years back, i'd have been shot on sight for suggesting that xlink:href should be changed to href |
| 21:52 | <Hixie_> | now, it's actually something that people might consider |
| 21:52 | <gsnedders> | on a totally unrelated note, does anyone have any reasons for wanting me to work on HTTP Parsing over the October holidays instead of various other things on my to-do list? |
| 21:52 | <gsnedders> | (anne is the most likely, but he isn't here right now) |
| 21:56 | <gsnedders> | (regardless of that, I should probably email Eric Woersching tonight about one or two things IIS does) |
| 22:15 | <gsnedders> | anyone have any thoughts on me requiring requests to comply with the RFC 2616 specification, otherwise the server MUST return 400 Bad Request? |
| 22:18 | <hsivonen> | gsnedders: I guess that depends on how hard it is for the server to validate the request against RFC 2616 requirements and if such validation is needed for interop |
| 22:18 | <gsnedders> | hsivonen: IIS seems to be fairly strict already |
| 22:18 | <hsivonen> | and if interop doesn't require servers *not* to validate |
| 22:19 | <Hixie_> | (which i imagine is the case) |
| 22:20 | gsnedders | drops email off to IIS technical product manager |
| 22:21 | <gsnedders> | in part asking if there is any reasoning why IIS is in places strict |
| 22:22 | <hsivonen> | I don't like the white space normalization step of xml:id. bad for perf |
| 23:45 | <jeremyb> | lastlog -clear |