| 00:02 | <GPHemsley> | Are IDs allowed to start with numbers now? |
| 00:02 | <AryehGregor> | Yes. |
| 00:03 | <AryehGregor> | They can be arbitrary nonempty strings that don't contain whitespace. |
| 00:07 | <GPHemsley> | k |
| 02:00 | <mikl0> | HTML5 is no longer an XML vocabulary? Just making sure I understand. |
| 02:03 | <MikeSmithX> | Hixie: here now |
| 02:07 | <Hixie> | mikl0: it's a DOM vocabulary, and there's an XML serialisation and a text/html serialisation |
| 02:10 | <mikl0> | Hixie: If I wanted to use an XML application like MathML I would do what to make everything valid use XML serialisation? MIME type of application/xhtml+xml or application/xml ? |
| 02:11 | <Hixie> | text/html (as of HTML5) supports the MathML, SVG, and HTML vocabularies |
| 02:11 | <Hixie> | for XML, you can use any MIME type text/xml, application/xml, or */*+xml |
| 02:11 | <Hixie> | as far as HTML5 goes |
| 02:13 | <mikl0> | Hixie: ah, that clears my confusion so HTML5 text/html is fine with MathML, SVG and HTML perfect! Thank you. |
| 02:23 | <TabAtkins> | mikl0: Just be careful when using namespaced elements. IIRC they sometimes don't act as you'd expect in the text/html serialization. |
| 02:25 | <mikl0> | TabAtkins: ok i will be and i plan on being here in the channel frequently as i work, to give back for others who have questions and to ask some of my own i'm sure. |
| 02:36 | <Hixie> | ok, so, elementary TCP questions ahoy. |
| 02:36 | <Hixie> | if i want to initiate a graceful close, it seems relatively easy |
| 02:37 | <Hixie> | I send a FIN (shutdown with SHUT_WR), then I wait until the socket is ready to read and recv() returns zero, then I call close(). |
| 02:37 | <Hixie> | but what does the other side do? |
| 02:37 | <Hixie> | If I'm in full swing of a connection, and my peer sends a FIN (recv() returns zero), what do I do to make sure that all my sent data gets to the other side? |
| 02:38 | <Hixie> | I can't call close(), because that will empty the send buffer and send a RST, as far as I can tell. |
| 02:38 | <Hixie> | I can't call shutdown() with SHUT_WR, because I'll have no way to know to move on to the next step, since recv() has already returned zero. |
| 02:49 | <Hixie> | hm, it seems i'm wrong about close() clearing the _send_ buffer |
| 02:49 | <Hixie> | what's going on is normally it sends an RST if there's any pending data to _read_, and _that_ causes the other side to throw away _its_ read buffer |
| 02:49 | <Hixie> | so |
| 02:49 | <Hixie> | a simple graceful shutdown can be done just by one side or the other sending a FIN |
| 02:50 | <Hixie> | then it waiting for recv()=0 and calling close() |
| 02:50 | <Hixie> | and the other side just calling close() |
| 02:50 | <Hixie> | when it gets recv()=0 |
| 03:06 | <foolip> | so where did this boblet fellow go? |
| 03:09 | <MikeSmith> | foolip: boblet comes and goes.. he's usually not on IRC, but mostly pops on when he has a question |
| 03:11 | <MikeSmith> | foolip: he's boblet on twitter as well, if you want to ping him there |
| 03:20 | <foolip> | MikeSmith: thanks |
| 03:33 | <mpilgrim> | i don't understand why we're still arguing about @longdesc |
| 03:33 | <mpilgrim> | richard schwerdtfeger said months ago that "longdesc was a disaster" ( http://lists.w3.org/Archives/Public/public-html/2009Sep/0596.html ) |
| 03:33 | <mpilgrim> | and his preferred replacement (ARIA) is already in html5 |
| 03:35 | <mpilgrim> | yet the same people who claim that data is irrelevant and that all decisions should be based on respect |
| 03:36 | <mpilgrim> | are still arguing that longdesc was not, in fact, a disaster |
| 03:39 | <mpilgrim> | it's almost as if appeals to authority only count when the authority shares your position |
| 03:39 | <Dashiva> | Or maybe it's a bit more subtle, people who don't share your position don't count as authorities :) |
| 03:40 | karlcow | |
| 06:33 | <boblet> | hey foolip, popping in ’cos I have a question :) |
| 06:34 | <foolip> | boblet: shoot |
| 06:34 | <boblet> | first thanks for Live Microdata—great stuff |
| 06:35 | <boblet> | main q is do you have any plans to make an auto-conversion service for downloading vcards a la X2V? or do you know of such a thing? |
| 06:36 | <foolip> | boblet: sorry, what's X2V? |
| 06:36 | <foolip> | do you mean pasting a URL and getting a vcard for download? |
| 06:37 | <boblet> | yep. sorry it’s prolly http://h2vx.com/ now |
| 06:38 | <foolip> | that would require some server-side stuff |
| 06:38 | <foolip> | I'd really like to have a python implementation to do that kind of thing |
| 06:39 | <foolip> | but I don't have a concrete plan to do it in the immediate future |
| 06:39 | <boblet> | ok, that’s good to know |
| 06:40 | <boblet> | there might be enough microdata support in html5lib btw |
| 06:40 | <foolip> | it would also be useful to e.g. let people see the microdata output (other than vcard) from their live sites |
| 06:40 | <foolip> | has someone been working on that? |
| 06:40 | <boblet> | I’m the wrong person to ask sorry |
| 06:40 | <boblet> | :) |
| 06:40 | <foolip> | jgraham, gsnedders? |
| 06:41 | <boblet> | I agree re: showing microdata output |
| 06:41 | <foolip> | in any case it should be layered on top of html5lib, that's for sure |
| 06:41 | <boblet> | I asked earlier when Tab & Philip were around, and they hadn’t heard of anything |
| 06:41 | <foolip> | boblet: if you have any bugs or patches for live microdata, feel free to send them (per mail or otherwise) |
| 06:42 | <foolip> | I'd like it to be able to validate known itemtypes, but haven't done so yet |
| 06:42 | <boblet> | foolip: well actually, itemprop="description" didn’t seem to work for me: http://oli-studio.com/temp/uf/microdata.html |
| 06:43 | <boblet> | no vevent output, but remove desc and it works |
| 06:43 | <foolip> | boblet: having a look |
| 06:44 | <boblet> | thanks |
| 06:45 | <foolip> | yep, there's a bug |
| 06:45 | <foolip> | one sec |
| 06:49 | <boblet> | yay! I helped |
| 06:51 | <foolip> | boblet: fixed a typo, try again now (make sure you reload properly) |
| 06:51 | <foolip> | s/subStr/substr/ was the trick :) |
| 06:52 | <foolip> | I also pushed some changes for RDF extraction that are in violation of the spec (but better :) |
| 06:52 | <boblet> | heh, oh that all bugs were that easy |
| 06:52 | <boblet> | thanks—it works great here |
| 06:53 | <foolip> | it only happened with description because only then was the line long enough to trigger the line wrapping code |
| 06:56 | <boblet> | one more q but need to check specs first… |
| 06:56 | foolip | will be loitering |
| 07:00 | <boblet> | foolip: nope, just mistaken expectations. |
| 07:01 | <boblet> | although I’ll definitely ping you if I come across anything else. Thanks again for your help! |
| 07:05 | <foolip> | good luck! |
| 07:09 | <MikeSmith> | Hixie: it's clear from the spec that <p spellcheck=""> and <p contenteditable=""> are conforming, but the spec seems to be ambiguous about whether <p spellcheck> and <p contenteditable> are conforming. |
| 07:11 | <Hixie> | where is a difference between the two expressed? |
| 07:11 | <MikeSmith> | Hixie: the difference is that in the first case the empty string is explicitly specified |
| 07:12 | <Hixie> | it's explicitly specified in the second case also |
| 07:12 | <Hixie> | unless we're talkign about different parts of the spec |
| 07:13 | <MikeSmith> | is there a place in the spec that says using empty-attribute syntax is equivalent to explictly including '=""' ? |
| 07:14 | <MikeSmith> | Hixie: the spec defines empty-attribute syntax but does not say it's equivalent to including ="" |
| 07:14 | <MikeSmith> | I realize that parsing algorithm makes it clear that empty attributes get assigned the empty string as values |
| 07:18 | <Hixie> | MikeSmith: hm, yeah, the syntax could be clearer about that. i'll file a bug, thanks. |
| 07:20 | <MikeSmith> | Hixie: I'm happy to file the bug if you want |
| 07:21 | <MikeSmith> | anyway, I think it's clear enough for those who read the parsing algorithm, just not for those who don't |
| 07:31 | <hsivonen> | what's the statistical charset detection situation in WebKit like these days? |
| 07:31 | <hsivonen> | does it have a statistical detector? how much data is fed to it? |
| 07:56 | <roc> | hsivonen: isn't charset conversion delegated to the platform layer, so each Webkit port has its own? |
| 07:57 | <hsivonen> | roc: that's possible. if so, I'm interested in what Safari on Mac and Chrome on Windows do |
| 07:59 | <Hixie> | what timezone is document.lastModified supposed to be in? |
| 08:01 | <othermaciej> | hsivonen: most WebKit ports use libicu for charset conversion |
| 08:01 | <othermaciej> | not sure if they all have it configured the same way though |
| 08:01 | <Hixie> | user's local timezone, it seems |
| 08:02 | <Hixie> | oh look, that's what the spec says |
| 08:02 | <Hixie> | excellent |
| 08:02 | <Hixie> | i'm ahead of myself |
| 08:10 | <Hixie> | annevk: btw dunno if you saw but i made the algoriothm support sync fetch |
| 08:14 | <hsivonen> | othermaciej: is the ICU detector used, too? Is it always on? Does it look at the first 1K or the whole page? |
| 08:15 | <othermaciej> | hsivonen: I do not know that offhand |
| 08:23 | <annevk> | Hixie, yeah thanks |
| 08:23 | <annevk> | Unicode characters include control points, no? |
| 08:25 | <Hixie> | i have to look it up each time |
| 08:29 | <annevk> | oh well, I guess I won't care about whether somewhat informative CSS descriptions are accurate |
| 08:41 | <jgraham> | foolip: ? |
| 08:43 | <annevk> | they're not configured in the same way, fwiw |
| 08:43 | <annevk> | e.g. Chrome has a lot of custom patches to ICU |
| 08:43 | <annevk> | Web Encodings is currently very low-priority though |
| 08:58 | <jgraham> | boblet: FWIW html5lib doesn't support microdata but I have a partial, buggy, implementation of an old version of the spec based on hml5lib |
| 08:58 | <jgraham> | "based on" meaning "that uses html5lib to parse the html" |
| 08:59 | <boblet> | jgraham: thanks for letting me know |
| 09:01 | <zcorpan__> | Hixie: i can access hixie.ch from here |
| 09:01 | <boblet> | I don’t think I’ll a chance to play with anything soon, but good to know for speech |
| 09:43 | <wycats> | Hixie: great job with my comments so far :) |
| 09:43 | <wycats> | I have a few flagged to come back to but almost everything looks great |
| 09:47 | <annevk> | bah |
| 09:48 | <annevk> | all that fetch gains me is no longer defining cookie semantics and referrer |
| 09:49 | <annevk> | I thought I could merge stuff |
| 09:49 | <annevk> | oh well, at least everything will use the same |
| 09:49 | <annevk> | oh, seems like CORS will need to depend on HTML5 again |
| 09:49 | <annevk> | people will be so pleased |
| 09:50 | <annevk> | getting things done vs getting things done perfect in infinite time is always an interesting discussion to have I suppose |
| 10:09 | <Huvet_> | is there an example somewhere of how to sanitize some random html? |
| 10:10 | <Huvet_> | http://dpaste.com/159820/ <- what I have so far |
| 10:10 | <Huvet_> | http://dpaste.com/159821/ <- my stacktrace |
| 10:14 | gsnedders | guesses it may just be broken |
| 10:14 | <gsnedders> | annevk: Yes, chars includes characters whose General_Category is C* |
| 10:15 | <jgraham> | Huvet_: That looks odd. I don't have time to dig into it right now though |
| 10:15 | <jgraham> | (sorry) |
| 10:15 | <jgraham> | But gsnedders guess looks quite reasonable |
| 10:15 | <Huvet_> | don't be sorry :) |
| 10:15 | <gsnedders> | Nor do I |
| 10:15 | <jgraham> | Try a different tree type? |
| 10:15 | <gsnedders> | I can just make mostly blind guesses from what people actually use and what we have lots of tests for |
| 10:15 | <Huvet_> | you don't have a working sanitizon sample handy? |
| 10:16 | <jgraham> | Also I may have added a sanitize function to the top level API... |
| 10:16 | <gsnedders> | "may". |
| 10:16 | <jgraham> | (but I'm not sure. I remember thinking it would be a good idea) |
| 10:16 | <gsnedders> | Awesome. |
| 10:16 | <gsnedders> | :) |
| 10:16 | <Huvet_> | :D |
| 10:16 | <annevk> | gsnedders, thanks, that's what I thought |
| 10:16 | <Huvet_> | yeah, that code is just messy, a toplevel API would be great |
| 10:17 | <gsnedders> | annevk: Basically any code point that is assigned and is neither a non-character nor a surrogate is a character |
| 10:17 | <annevk> | right, that's what I thought (and just said in email) |
| 10:50 | <annevk> | whoa, last TR/ version of CORS was in March |
| 10:50 | <jgraham> | TR/++ |
| 10:50 | <annevk> | this UM debacle stalled things quite a bit |
| 12:38 | <annevk> | omg |
| 12:38 | <annevk> | well, it's not that bad, but I'm yet again looking at this security consideration request for XHR and I've no idea what to put in |
| 12:40 | <asmodai> | annevk: "unnecessary"? :) |
| 12:41 | <annevk> | that has been my argument so far, yes :) |
| 12:42 | <annevk> | security requirements are made throughout the specification and I see no reason to explain those more than other kind of requirement |
| 12:42 | <annevk> | (besides that I've no idea how to explain some of them) |
| 12:43 | <annevk> | (if you read this in the logs and you think this is all wrong, please instead of thinking that propose how to fix it on public-webapps⊙wo, cheerio) |
| 12:43 | <smaug> | Hixie: in which way should websocket send buffered messages; I mean if someone is doing for (i = 0; i < 100000; ++i) socket.send("Somedata"); should there be 100000 websocket frames, or can the client merge messages and have fewer frames? |
| 12:44 | <annevk> | there should be 100000 frames |
| 12:45 | <smaug> | annevk: based on what? |
| 12:45 | <smaug> | I do agree that 100000 sounds better |
| 12:45 | <annevk> | the spec? it would be annoying if e.g. send("+1"); send("+2") turns into a single frame "+1+2" |
| 12:45 | annevk | looks at spec |
| 12:45 | <smaug> | that way server can handle messages the same way, even if client needs to buffer |
| 12:46 | <smaug> | but I don't see anything in Websockets API that requires that behavior |
| 12:47 | <annevk> | I do |
| 12:47 | <annevk> | see definition of *send /data/ using the Web Socket* |
| 12:48 | <annevk> | it's very explicit |
| 12:49 | <hsivonen> | the questions I got after my lecture were about Microdata and RDF, then Microdata and RDFa |
| 12:50 | <hsivonen> | it seems the students perceived Microdata/RDFa as the most controversial thing in HTML5 above video codecs |
| 12:50 | <annevk> | lots of RDF classes? |
| 12:51 | <annevk> | and not so much on open Web? |
| 12:51 | <hsivonen> | possibly. or RDFa assigned as an exercise topic maybe |
| 12:51 | <hsivonen> | geolocation is one of the exercise topics |
| 12:52 | <hsivonen> | pairs of students get an assigned topic to prepare a 20-minute presentation on |
| 12:53 | <Yudai> | hi guys, may i ask a question? |
| 12:54 | <Yudai> | is it ok to add a fragment id to a URI with data scheme? |
| 12:54 | <hsivonen> | Yudai: IIRC, no |
| 12:54 | <hsivonen> | unfortunately |
| 12:54 | <Yudai> | oh, really? let me know why |
| 12:54 | <smaug> | annevk: send data using web socket, how is that explicitly saying that a frame is generated? |
| 12:55 | gsnedders | doesn't think it's defined what a data URI with a scheme means, nor whether it's valid |
| 12:55 | <hsivonen> | Yudai: what looks like a fragment gets treated as content data |
| 12:55 | <gsnedders> | Browsers treat # within a data URI as part of the data though, AFAIK |
| 12:56 | <annevk> | smaug, it's a term defined in the protocol spec |
| 12:56 | <annevk> | smaug, where it says in three steps how to construct the frame |
| 12:57 | <smaug> | annevk: right. but how do you interpret "send data using web socket" to mean that it creates one frame |
| 12:58 | <smaug> | I read it so that "send data" just says that data is sent in some way using web socket |
| 12:58 | <annevk> | i just told you |
| 12:58 | <smaug> | maybe even 1 char at time |
| 12:58 | <annevk> | i guess i need to give a pointer... |
| 12:59 | <smaug> | annevk: ah |
| 12:59 | <annevk> | see the end of this section http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-75#section-4.2 |
| 12:59 | <smaug> | I found it in the protocol |
| 12:59 | <smaug> | very annoying way to define it |
| 12:59 | <annevk> | that's what I said :/ |
| 12:59 | <Yudai> | hsvinoen: however, a "#" character should be escaped if it is on the data part, I think |
| 12:59 | <smaug> | wording should be improved |
| 13:00 | <gsnedders> | Yudai: Per spec, yes |
| 13:00 | <annevk> | i guess |
| 13:01 | <annevk> | i'm sure Hixie is not out to get you so if you find something is confusing constructive feedback would help |
| 13:01 | <Yudai> | gsnedders: so it's the end of data part if a parser find "#" on a URI |
| 13:04 | <gsnedders> | Yudai: Theoretically per spec, yes. |
| 13:04 | <gsnedders> | Yudai: In terms of what impls do and what the web requires, no |
| 13:05 | <Yudai> | gsnedders: ok, i see |
| 13:05 | <Yudai> | validator.nu raises an error in this case |
| 13:06 | <Yudai> | it might get people confused |
| 13:10 | <Yudai> | gsnedders: btw, I could not understand what you mean with your message on 22:01 because of my poor english |
| 13:13 | <Yudai> | i'm sorry. let me know the meaning with other words if possible |
| 13:16 | <Yudai> | MikeSmith: could you show me the way to add a new bug to the tracker of validator.nu? |
| 13:29 | <annevk> | so new Anon[XMLHttp]Request() or new XMLHttpRequest(anon=true) |
| 13:30 | <annevk> | Hixie seemed to have a preference for the latter and since I don't really care I'm leaning towards that too, but if anyone has input? |
| 13:33 | <asmodai> | I'd lean to the latter, but I am one of those evil Python programmers. :) |
| 13:35 | <annevk> | ah, the way it would work is new XMLHttpRequest() makes it default to false, whereas new XMLHttpRequest(true) gives you anonymous requests |
| 13:36 | <annevk> | i guess that is good enough; it also does not introduce much API clutter |
| 13:37 | <TabAtkins> | annevk: new XMLHttpRequest({anon:true}) |
| 13:38 | <annevk> | no |
| 13:39 | <annevk> | hmm, it would be sort of neat to hide certain functionality but I guess throwing some exceptions is better |
| 13:53 | <TabAtkins> | >_< We'll never get the object-argument pattern into apis is nobody starts them. >_< |
| 13:54 | <annevk> | true words |
| 13:56 | <smaug> | annevk: I'd prefet the first one. That explicitly says that an AnonXHR is being created |
| 13:56 | <smaug> | prefer |
| 13:57 | <annevk> | it's exactly the same object, just with a flag set differently |
| 13:57 | <annevk> | internal flag, that is |
| 13:57 | <smaug> | ah, the difference will be so small |
| 13:57 | <smaug> | then a flag is perhaps better |
| 13:58 | <smaug> | optional flag, ofc |
| 13:58 | <annevk> | yes, the internal flag affects the last two arguments of open(), withCredentials, and the XMLHttpRequest origin |
| 13:58 | <annevk> | basically, my plan is throw for the last two arguments of open, to throw for withCredentials, and to set the XMLHttpRequest origin to a unique identifier |
| 13:59 | <annevk> | I think that deals with everything and obsoletes the need for UM |
| 14:05 | <annevk> | lets try to spec this |
| 14:24 | <MikeSmith> | hsivonen: you around? |
| 14:25 | <MikeSmith> | wanted to ask about a potential bug that Yudai has been looking at |
| 14:28 | <hsivonen> | MikeSmith: I'm around for a few minutes still |
| 14:29 | <MikeSmith> | Yudai: can you please explain your test case to hsivonen ? |
| 14:29 | <Yudai> | ok, i see |
| 14:30 | <Yudai> | the validator raises an error when an data: URI with a fragment id (like data:....#id) is in the page |
| 14:31 | <Yudai> | s/an data:/a data:/ |
| 14:31 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=data%3Atext%2Fhtml%3Bcharset%3DUTF-8%3Bbase64%2CPCFkb2N0eXBlIGh0bWw%2BCjxodG1sPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPgo8dGl0bGU%2BSGVsbG8gQmFzZTY0PC90aXRsZT4KPGxpbmsgcmVsPSJzdHlsZXNoZWV0IiBocmVmPSJkYXRhOnRleHQvY3NzO2NoYXJzZXQ9VVRGLTg7YmFzZTY0LGFIUnRiSHNLQ1dobGFXZG9kRG9nTWpBd01IQjRPd29KYjNabGNtWnNiM2M2SUdocFpHUmxianNLZlFwd2V3b0piV0Z5WjJsdU |
| 14:31 | <MikeSmith> | 9pQXdPd29KY0dGa1pHbHVaem9nTURzS0NXWnZiblF0YzJsNlpUb2dPVFp3ZURzSkNnbG1iMjUwTFhkbGFXZG9kRG9nWW05c1pEc0tmUW9qWW1GelpUWTBld29KYldGeVoybHVMWFJ2Y0RvZ01qVTJjSGc3Q24wSyIgdHlwZT0idGV4dC9jc3MiPgo8L2hlYWQ%2BCjxib2R5Pgo8cCBpZD0iaGVsbG8iPjxhIGhyZWY9IiNiYXNlNjQiPkhlbGxvITwvYT48L3A%2BCjxwIGlkPSJiYXNlNjQiPldlbGNvbWUgdG8gdGhlIFdvcmxkIG9mIEJhc2U2NCE8L3A%2BCjwvYm9keT4KPC9odG1sPgo%3D%23base64 |
| 14:31 | <hsivonen> | Yudai: is #id allowed per the data: URL spec? at least given browser behavior, it seems useful to treat it as an error |
| 14:32 | <MikeSmith> | oops |
| 14:33 | <MikeSmith> | hsivonen: validator.nu seems to be down at the moment |
| 14:33 | <myakura> | https://bugzilla.mozilla.org/show_bug.cgi?id=243917 |
| 14:33 | <Yudai> | hsivonen: perhaps yes |
| 14:33 | <Yudai> | https://bugzilla.mozilla.org/show_bug.cgi?id=243917 |
| 14:34 | <Yudai> | hsivonen: and i agree with that |
| 14:34 | <Yudai> | however i found a person confused by that behavior |
| 14:34 | <hsivonen> | it's confusing, sure |
| 14:35 | <hsivonen> | MikeSmith: thanks. that's odd |
| 14:35 | <MikeSmith> | hsivonen: maybe I crashed it with that test case |
| 14:36 | <hsivonen> | MikeSmith: back up now |
| 14:36 | <MikeSmith> | cool |
| 14:37 | <MikeSmith> | myakura, Yudai - from my reading of the Mozilla bug, the only use case mentioned for XBL, and comments in https://bugzilla.mozilla.org/show_bug.cgi?id=366770 seem to indicate it's no longer needed for XBL |
| 14:37 | <MikeSmith> | so are there other use cases? |
| 14:37 | MikeSmith | goes back to read the blog post |
| 14:38 | <Yudai> | MikeSmith: the person myakura (and I) found wanted to access to the fragment of html in data: uri |
| 14:40 | <MikeSmith> | Yudai: I see. But I guess the next question is why does he want to do that and/or why does he think others would want to do that? |
| 14:40 | <Yudai> | hmm, RFC2396 says: This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. |
| 14:40 | hsivonen | goes away |
| 14:41 | <MikeSmith> | Yudai: it seems pretty clear that fragment IDs in data: URIs are not valid |
| 14:41 | <MikeSmith> | that doesn't mean browsers can't handle them if they choose to |
| 14:42 | <Yudai> | yes, i agree |
| 14:43 | <myakura> | he was just trying to show that opera does *right* about data: uri so i don't think that doesn't convey any use cases |
| 14:44 | <MikeSmith> | OK |
| 14:44 | <gsnedders> | myakura: Our behaviour has changed in 10.50 anyway |
| 14:45 | <MikeSmith> | anyway, because it seems that not all browsers handle fragment IDs in URIs, validator.nu is doing the right thing by reporting it as an error, both in terms of what the RFCs/specs say and in terms of best practice |
| 14:46 | <myakura> | hmm, that still seems to work with my 10.50 Beta http://software.hixie.ch/utilities/js/live-dom-viewer/saved/377 |
| 14:46 | <Yudai> | MikeSmith: I think validator should work according to specs not to implementation |
| 14:47 | Yudai | is not sure it is valid or not |
| 14:48 | <Philip`> | I think specs should work according to implementations |
| 14:50 | <gsnedders> | myakura: Uh, what's that testing? |
| 14:51 | <gsnedders> | myakura: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/378 is what I mean |
| 14:52 | <Yudai> | i thought RFC2397 defines a "absoluteURI" part in RFC2045 |
| 14:53 | <Yudai> | but it seems wrong. RFC2397 seems define whole URI |
| 14:53 | <myakura> | gsnedders: ah! |
| 14:54 | <annevk> | Yudai, those RFCs are out of date |
| 14:54 | <annevk> | well, some of those |
| 14:54 | <annevk> | use http://tools.ietf.org/html/rfcXXXX to see which |
| 14:55 | <myakura> | well, Yudai and I were talking about Opera points to "Welcome ..." when clicking "Hello!" http://software.hixie.ch/utilities/js/live-dom-viewer/saved/379 |
| 14:55 | <myakura> | and wondered whether it should or not. |
| 14:56 | <MikeSmith> | "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." |
| 14:56 | <annevk> | yes, that ought to work |
| 14:56 | <annevk> | Gecko/WebKit have bugs |
| 14:56 | <Yudai> | annevk: oops. thanks |
| 14:56 | <myakura> | interesting. |
| 14:57 | <Yudai> | oooh? |
| 14:57 | <jre> | RFC 2396 is obsoleted by RFC 3986 |
| 14:57 | <jre> | fragment identifier syntax is completely orthogonal to URI schemes |
| 14:58 | <myakura> | Hmm. RFC 2397 says 'where "urlchar" is imported from [RFC2396]' but there's no such in 2396... |
| 14:58 | <jre> | so a URI scheme definition shouldn't mention fragment identifiers at all |
| 14:59 | <Yudai> | 2396 is older...3986 is newer... i mistake them everytime :( |
| 15:00 | <jre> | higher numbers usually are newer |
| 15:03 | <Yudai> | yes, i know. the problem is when given only 2396. |
| 15:03 | <Yudai> | 2396 and 3986 are similar for me... |
| 15:04 | <Yudai> | then, data: uri with a fragment id is valid? |
| 15:04 | <jre> | of course |
| 15:05 | <Yudai> | i see |
| 15:07 | <Yudai> | MikeSmith: it is better to change the error to warning, i think |
| 15:09 | <MikeSmith> | Yudai: changing it to a warning is technically doable, but it's not clear yet it's the right thing is this case |
| 15:12 | <Yudai> | MikeSmith: hmm, i think that people believe that a validator suits specs |
| 15:18 | <Yudai> | Philip's remark might be right, but the RFC is already issued |
| 15:19 | <Yudai> | anyway, we need hsivonen's comments |
| 15:22 | <annevk> | is dev.w3.org offline or so? |
| 15:22 | <annevk> | cvs diff seems to be very very slow |
| 15:26 | <myakura> | MikeSmith: btw have you found anyone who can do some interpretation work for you (and Oli) tomorrow night? |
| 15:26 | <MikeSmith> | myakura: I've not, but if you will be there and can do it, I'd be happy if you could |
| 15:27 | <MikeSmith> | I have had very little time to do as much preparation as I would have liked to |
| 15:27 | <MikeSmith> | there's been a few other things going on the last few days... |
| 15:30 | <myakura> | MikeSmith: Sure I'd love to do, so that I can sneak into the place :) (I'd totally missed registering for the event) |
| 15:32 | <danbri> | from elsewhere on the internet, 'the minute I see the first porn site switch to HTML5 I know Flash has lost...' |
| 15:32 | <danbri> | any progress on that front? |
| 15:37 | <MikeSmith> | myakura: can you please e-mail Shiraishi-san and Cc me and let him know I requested that you be there to do interpretation for me as needed? |
| 15:39 | <TabAtkins> | Argh, damn you float-based layouts! ::shakes fist:: |
| 15:42 | <annevk> | ok |
| 15:42 | <annevk> | new XMLHttpRequest(anon) is defined now |
| 15:42 | <annevk> | I had a few people asking other questions which is why it was somewhat delayed |
| 15:46 | <Philip`> | annevk: In the IDL, shouldn't "Constructor(anon)" be "Constructor(bool anon)" or similar? |
| 15:46 | <Philip`> | Also, shouldn't the IDL have "in" in front of every function argument? |
| 15:47 | <annevk> | yes, no |
| 15:49 | <annevk> | Philip`, boolean added |
| 15:56 | <karlushi> | ooops validator.nu seems to be down. |
| 15:57 | <annevk> | you can still use http://html5.validator.nu/ it seems |
| 15:57 | <MikeSmith> | I think beacuse those are actually two different instances |
| 15:58 | <karlushi> | annevk, ah thanks. |
| 15:58 | <MikeSmith> | http://qa-dev.w3.org:8888/ works too, but is running unstable code |
| 16:03 | <karlushi> | was looking at http://dev.w3.org/html5/markup/form.html#form.attrs.accept-charset |
| 16:04 | <karlushi> | and it doesn't seem there is an explanation in which order you should process the space separated values list of encoding |
| 16:05 | karlushi | is going to the spec |
| 16:05 | <karlushi> | http://dev.w3.org/html5/spec/forms.html#attr-form-accept-charset |
| 16:07 | <Philip`> | karlushi: http://whatwg.org/html#url-encoded-form-data |
| 16:07 | <Philip`> | Step 2 is where it defines the processing of accept-charset |
| 16:08 | <Philip`> | i.e. UAs can pick whichever they think is going to work best |
| 16:08 | <karlushi> | hmmm |
| 16:08 | <karlushi> | I thought the order was meaningful |
| 16:09 | <Philip`> | It has no meaning defined by the spec, it seems |
| 16:09 | <Philip`> | It's just a list of charsets that the server will accept |
| 16:10 | <Philip`> | and there's no reason for the server to have preferences, since it'll decode them all equally into Unicode |
| 16:10 | <karlushi> | If specified, the value must be an ordered set of unique space-separated tokens |
| 16:10 | <karlushi> | -- quote from the spec |
| 16:10 | <Philip`> | The UA might choose to derive some meaning from the order |
| 16:10 | <annevk> | we should obsolete accept-charset |
| 16:10 | <karlushi> | ok |
| 16:11 | <annevk> | people ought to use UTF-8 |
| 16:11 | <karlushi> | so if I understood well: accept-charset="ISO-8859-1 utf-8" == accept-charset="utf-8 iso-8859-1" |
| 16:11 | <Philip`> | annevk: People might want to migrate their site to UTF-8 gradually, by making their forms accept UTF-8 even if the outer page is stuck on Win1252 |
| 16:12 | <Philip`> | in which case they need to use accept-charset |
| 16:13 | karlushi | is trying to figure out the issues/benefits of <form … accept-charset="ISO-8859-1 utf-8"> |
| 16:13 | <annevk> | Philip`, we could make it like border= with only one allowed value |
| 16:13 | <annevk> | karlushi, why? |
| 16:13 | <annevk> | karlushi, use UTF-8, much superior |
| 16:13 | <Philip`> | karlushi: Not necessarily equal - a UA might choose to prefer ones that are earlier in the list, and the spec doesn't forbid or require that |
| 16:13 | <karlushi> | because it is confusing for developers right now, and we found that in legacy code. |
| 16:14 | <annevk> | sounds like a good reason to make it obsolete but conforming or some such |
| 16:14 | <karlushi> | annevk, I'm entirely for utf-8, but my own client real world for now makes it difficult ;) |
| 16:17 | <Philip`> | Comma separate accept-charsets look much more common than space-separated |
| 16:17 | <Philip`> | *separated |
| 16:17 | <karlushi> | Philip`, indeed. Right now the form is with comma separated values |
| 16:19 | <Philip`> | http://philip.html5.org/data/form-accept-charset.txt |
| 16:24 | <Philip`> | (Interestingly, the people using "windows-1252,iso-8859-1" are going to get UTF-8) |
| 17:07 | <annevk> | hmm, my email appears not to arrive at the W3C or something |
| 17:07 | <annevk> | weird |
| 17:08 | <TabAtkins> | I've been getting your emails, annevk. |
| 17:09 | <annevk> | I realize that, 'cause I do get replies :) |
| 17:09 | <annevk> | it's just they don't appear on the list |
| 17:09 | <TabAtkins> | Oh, huh. |
| 17:10 | <annevk> | indeed |
| 17:10 | <annevk> | time for conspiracy theories! |
| 17:10 | <annevk> | or a break... I guess I'll take a break |
| 17:11 | <TabAtkins> | Either option sounds reasonable to me. |
| 17:11 | TabAtkins | headdesks. |
| 17:12 | <TabAtkins> | Of *course* a transparent background image won't look transparent *if you use an opaque background color*. |
| 17:13 | <jgraham> | Huh? |
| 17:13 | <TabAtkins> | I am dumb, jgraham. |
| 17:13 | <gsnedders> | TabAtkins: That's self-evident. |
| 17:13 | <TabAtkins> | Fuck you, gsnedders ^_^ |
| 17:14 | <jgraham> | Don't swear in front of the children |
| 17:14 | <jgraham> | Or at them, rather :) |
| 17:14 | <TabAtkins> | Oh right, sorry. Would you like a lollipop, gsnedders? |
| 17:18 | <TabAtkins> | Yay, I get to use my gradients in a production site! |
| 17:18 | <TabAtkins> | As the final background rule in a series of 3, targetting various levels of support, but still! |
| 17:19 | <annevk> | oh lol, first comment on http://news.ycombinator.com/item?id=1126460 |
| 17:19 | <annevk> | seems also very true |
| 17:20 | <TabAtkins> | Yup, we were discussing that from a different source yesterday. ^_^ |
| 17:23 | <jgraham> | It's kinda curious that Hixie gets so much grief for having a "Yes Minister" quote on his site when there are so many actual examples of people engaging in behaviour that fits that mould (one assumes unintentionally) |
| 17:24 | <annevk> | oh, email is getting through again |
| 17:27 | <annevk> | (8) Be worried about the propriety of any decision -- raise the |
| 17:27 | <annevk> | question of whether such action as is contemplated lies within the |
| 17:27 | <annevk> | jurisdiction of the group or whether it might conflict with the policy |
| 17:27 | <annevk> | of some higher echelon. |
| 17:27 | <annevk> | seems applicable |
| 18:01 | <karlushi> | annevk, coming from http://www.gutenberg.org/files/26184/26184-8.txt |
| 18:04 | <annevk> | yeah |
| 18:04 | <annevk> | forgot attribution, ta |
| 18:08 | <TabAtkins> | This is probably the most fun project I've ever done, because it's full of a lot of simple, cool visual effects that I can do really easily while maintaining accessibility. |
| 18:19 | <annevk> | I wonder if Adobe threatened to leave the W3C or something... Larry did far more than raise "procedural concerns" |
| 18:20 | <annevk> | HTML minutes say FO, his own public email says "object" and what he needs to do to record it formally... |
| 18:20 | <annevk> | in response to http://www.w3.org/QA/2010/02/working_group_publication_requ.html |
| 18:21 | <TabAtkins> | Indeed. |
| 18:27 | <wycats> | annevk: also, weren't these issues raised AAAAAGES ago? |
| 18:27 | <wycats> | there are some emails on the public list that indicate that it went all the way up to the director |
| 18:27 | <wycats> | (already) |
| 18:30 | <annevk> | well yeah, I pointed out part of that |
| 18:30 | <annevk> | he seems to know want that either the SotD is changed or that we are re-chartered |
| 18:32 | <annevk> | if everyone acted this way we would not get very far |
| 18:32 | <annevk> | and now it's taking way too much time of everyone |
| 18:34 | <wycats> | annevk: but that exact point was already raised |
| 18:34 | <wycats> | like a year ago |
| 18:34 | <wycats> | and it was decided that rechartering was not needed |
| 18:35 | <wycats> | people are taking the opportunity to impugn Hixie and WHATWG |
| 18:46 | <annevk> | wycats, yeah, those twats always do |
| 18:49 | <AryehGregor> | Unfortunately, sometimes WHATWG contributors aren't as diplomatic as they could be. |
| 18:49 | <AryehGregor> | (Nor are the people who disagree with them, but still.) |
| 18:50 | <wycats> | :/ |
| 18:50 | <wycats> | I feel the people touting the awesomeness of the W3C process forget why this situation came to pass in the first place |
| 18:51 | <AryehGregor> | I feel the WHATWG's creation sort of parallels the W3C's creation, after reading TBL's "Weaving the Web". IETF -> W3C -> WHATWG. |
| 19:07 | <Philip`> | wycats: The canvas charter decision was at the end of 2007 |
| 19:08 | <Philip`> | (assuming that's what you're referring to) |
| 19:08 | <Philip`> | http://lists.w3.org/Archives/Public/public-html/2007Dec/0094.html |
| 19:10 | <wycats> | Philip`: yep |
| 19:10 | <wycats> | sorry... I should have said yeeeears ago ;) |
| 19:10 | <wycats> | AryehGregor: yah |
| 19:10 | <wycats> | great book |
| 20:11 | <Hixie> | smaug: the websocket spec in complete.html is a better experience (the cross-references work, for one), if you don't mind the size of that file |
| 20:11 | <Hixie> | smaug: i totally agree that splitting up the API and the protocol is dumb |
| 20:22 | <smaug> | Hixie: indeed. I wish there was just one specification |
| 20:23 | smaug | doesn't remember why the protocol is in hybi wg |
| 20:25 | <MikeSmithX> | smaug: because the standards-development fun needs to be spread out as widely as possible |
| 20:39 | <TabAtkins> | omg 49 bug emails at once. |
| 21:01 | <Dashiva> | Hum... |
| 21:03 | <Dashiva> | There doesn't seem to be anything about math and svg in the UA stylesheet section. Doesn't that mean a UA that doesn't support them will render all the contents as text? |
| 21:08 | zcorpan__ | held a presentation today on html5 video; slides at http://simon.html5.org/presentations/html5-video/ (in swedish) |
| 21:12 | <zcorpan__> | wonder if i need to pay royalties for having an mpeg4/h.264/aac file on my server |
| 21:13 | <zcorpan__> | well, annevk's server |
| 21:15 | <jwalden> | I believe the current answer to that question is "no" |
| 21:16 | <zcorpan__> | because my use is non-commercial? |
| 21:17 | <jwalden> | because payment's not required to view it |
| 21:18 | <zcorpan__> | i thought payment was required for distribution |
| 21:19 | <Dashiva> | Not if you don't charge for it |
| 21:19 | <jwalden> | ^ |
| 21:20 | <Dashiva> | "Internet broadcast" category |
| 21:20 | <zcorpan__> | ah |
| 21:21 | <jwalden> | what's "spela baklänges " mean? |
| 21:21 | <zcorpan__> | play backwards |
| 21:22 | <jwalden> | <video> really mandates backwards-playing support? color me surprised |
| 21:23 | <zcorpan__> | it does |
| 21:24 | Philip` | wonders what significant differences Martin Kliehm thinks exist between the two canvas split drafts |
| 21:31 | <Dashiva> | jwalden: Yeah, but sound is optional |
| 21:31 | <Dashiva> | http://www.thehistorian.org/2010/02/15/historians-social-media-party/ |
| 21:31 | <jwalden> | that only makes it slightly less surprising :-) |
| 23:43 | <hober> | Philip`: the bit under "Editors:" in the front-matter, I'm guessing |
| 23:46 | <carllerche> | Is there any way to do canvas style composting but with CSS in webkit / FF? |