| 05:28 | <Hixie> | where's hsivonen when you need him |
| 05:28 | <Hixie> | or ms2ger |
| 05:28 | <Hixie> | is anyone around who cares about keeping the whatwg and w3c specs in sync? |
| 05:29 | <Hixie> | how about any opera people? |
| 05:29 | <Hixie> | ok fine |
| 05:29 | Hixie | will just make something up |
| 05:43 | <Hixie> | the definition of makework, courtesy of julian and the chairs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11183 |
| 08:30 | <annevk> | morning |
| 08:35 | <zcorpan> | morning |
| 08:37 | <annevk> | hmm, one new email from Microsoft |
| 08:38 | <annevk> | apparently they have not read the "Goals" section |
| 08:40 | <zcorpan> | r6479 sounds a bit like "if you call within 15 minutes -- you heard right, within 15 minutes -- you will get this semantic dust sweeper WITHOUT EXTRA CHARGE!" |
| 08:42 | <annevk> | zcorpan, pointer? it's not on HTML5 Tracker |
| 08:43 | <zcorpan> | yeah it is |
| 08:44 | <zcorpan> | editorial change |
| 08:46 | <annevk> | well editorial changes make it there too normally |
| 08:48 | <zcorpan> | http://html5.org/tools/web-apps-tracker?from=6478&to=6479 |
| 08:50 | <annevk> | that is weird |
| 08:51 | <annevk> | I wonder how that happened |
| 09:10 | <annevk> | hmm |
| 09:10 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=312019 suggests the namespace algorithms in DOM Core are flawed |
| 09:14 | <zcorpan> | what, there are bugs with namespace algorithms? not possible |
| 09:14 | <annevk> | sssh |
| 09:14 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=505178 suggests the algorithm needs changing, but nobody followed up thus far |
| 09:14 | annevk | added a comment asking for feedback |
| 10:18 | <MikeSmith> | wow, http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ is seriously great |
| 10:19 | <MikeSmith> | have never before seen anybody actually write all this up |
| 10:19 | <MikeSmith> | paul_irish: ↑ kudos to you Tali man |
| 10:20 | <MikeSmith> | people are going to get tired of hearing me talk about that article |
| 10:22 | <MikeSmith> | hmm, some great stuff in the Resources section also |
| 10:22 | <MikeSmith> | http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Resources |
| 10:23 | <zcorpan> | MikeSmith: ok, great article, now stop talking about it :P |
| 10:23 | <MikeSmith> | heh |
| 10:24 | <Ms2ger> | Unfortunately it contains nonsense about DTDs |
| 10:25 | <MikeSmith> | oh really? |
| 10:25 | <MikeSmith> | hmm yeah |
| 10:25 | <Ms2ger> | And its definition of "Really lousy HTML" looks rather clean to me :) |
| 10:26 | <zcorpan> | just four errors |
| 10:27 | <zcorpan> | of which two are parser errors |
| 10:27 | <MikeSmith> | it correctly doesn't actually claim that browsers do anything with DTDs, and given that the article is about what browsers do, the stuff about DTDs could (should) just be yanked |
| 10:27 | <Ms2ger> | google.com probably hits more than that without trying |
| 10:28 | <zcorpan> | MikeSmith: i dunno if the article tries to set straight misconseptions, but if it does in general then it could talk briefly about how browsers *don't* use DTDs |
| 10:29 | <MikeSmith> | yeah |
| 10:29 | <MikeSmith> | notes for paul_irish |
| 10:29 | <MikeSmith> | the mention of DTDs seems to only be there to support the point that there is no context-free grammar for HTML |
| 10:29 | <MikeSmith> | it should instead mention the HTML5 parsing algorithm, and link to it |
| 10:30 | <Ms2ger> | It does somewhat further down, actually |
| 10:30 | <zcorpan> | the stray table example is wrong |
| 10:30 | <MikeSmith> | Ms2ger: oh, ok |
| 10:31 | <MikeSmith> | it also says, "The vocabulary and syntax of HTML are defined in specifications" but doesn't mention the parsing rules are also defined in a spec now |
| 10:32 | <Ms2ger> | The HTML definitions can be found here: www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html. |
| 10:32 | <MikeSmith> | actually, I see now that this article is mostly from an earlier document from Tali |
| 10:32 | <zcorpan> | "www.liceo.edu.mx is an example of a site that achieves a level of nesting of about 1500 tags, all from a bunch of <b>s. We will only allow at most 20 nested tags of the same type before just ignoring them all together." - the spec doesn't have this limit hard-coded right? |
| 10:32 | <MikeSmith> | http://taligarsiel.com/Projects/howbrowserswork1.htm |
| 10:33 | zcorpan | wonders if the code snippets are from webkit's old parser |
| 10:34 | <jgraham> | The bit about parsing is very confusing |
| 10:34 | <jgraham> | "Every format you can parse must have deterministic grammar consisting of vocabulary and syntax rules. It is called a context free grammar" |
| 10:34 | <zcorpan> | if (t->isCloseTag(brTag) && m_document->inCompatMode()) { suggests so |
| 10:34 | <jgraham> | Well clearly no |
| 10:34 | <jgraham> | t |
| 10:35 | <MikeSmith> | jgraham: yeah, that bit is self-contradictory |
| 10:35 | <annevk> | note that it was not written by paul_irish |
| 10:35 | <annevk> | he edited it |
| 10:35 | <MikeSmith> | OK |
| 10:35 | <MikeSmith> | yeah |
| 10:35 | <Ms2ger> | Could have edited a bit more ;) |
| 10:35 | <MikeSmith> | yeah, it clearly needs some more editing love |
| 10:35 | <annevk> | the original is from Tali Garsiel based on research on Gecko/WebKit |
| 10:35 | <annevk> | guess that was a while ago |
| 10:35 | <MikeSmith> | for this kind of document, maybe they should move the source to github or somewhere and accept patches |
| 10:36 | <jgraham> | In fact, what is the point of all the section describing parser theory? |
| 10:37 | <annevk> | jgraham, didn't get that either |
| 10:37 | <MikeSmith> | to set some context? |
| 10:37 | <jgraham> | MikeSmith: It reads a bit like someone has tried to summarise the wikipedia article on parsing |
| 10:37 | <Ms2ger> | s/github/Bitbucket/ |
| 10:38 | <jgraham> | I would prefer just a link to wikipedia |
| 10:38 | <MikeSmith> | jgraham: it is a pretty longish overall, too |
| 10:38 | <MikeSmith> | trimming some stuff out would make it an easier read |
| 10:39 | <Ms2ger> | MikeSmith, well, browsers are big ;) |
| 10:39 | <jgraham> | and yes, the bit about DTDs is very misleading |
| 10:39 | <jgraham> | Ms2ger: Yeah, so best not to waste space with background material that is better covered elsewhere |
| 10:39 | <zcorpan> | MikeSmith: trimming stuff that have little to do with browser internals would make it more focused on the topic |
| 10:40 | <MikeSmith> | Ms2ger: yeah, so big that when writing about how they work, it's best to omit stuff that's not really related at all to how browsers work |
| 10:40 | <MikeSmith> | zcorpan: what you said :) |
| 10:40 | <jgraham> | There are also a number of spelling/grammar mistakes but I will let timeless point those out |
| 10:40 | <MikeSmith> | and what jgraham said |
| 10:40 | <MikeSmith> | you dudes type faster than me |
| 10:40 | <MikeSmith> | or maybe you think faster |
| 10:41 | <zcorpan> | we have faster internets |
| 10:41 | <MikeSmith> | heh |
| 10:41 | <zcorpan> | fatter tubes |
| 10:41 | <MikeSmith> | tmi |
| 10:42 | <jgraham> | Is that HTML parsing comment really in the new webkit parser? It seems very pre-HTML5 |
| 10:42 | <foolip> | anyone know who nimbu is? |
| 10:43 | <Ms2ger> | foolip, Opera employee ;) |
| 10:43 | <zcorpan> | jgraham: i already concluded that the snippets must be from the old parser |
| 10:43 | <zcorpan> | jgraham: if (t->isCloseTag(brTag) && m_document->inCompatMode()) { |
| 10:44 | <foolip> | Ms2ger, ah, it's Divya Manian it seems |
| 10:44 | <jgraham> | The part of script scheduling is… not complete |
| 10:44 | <jgraham> | (on |
| 10:45 | <Ms2ger> | jgraham, well, would anybody get through it if it was? |
| 10:46 | <jgraham> | Well fair point, but one should at least point out that things are much more complex than they appear |
| 10:46 | <jgraham> | <head> goes in the render tree if you set it to display:block or something |
| 10:49 | <jgraham> | No ecmascript? |
| 10:49 | jgraham | skimmed most of the style/layout bit |
| 10:52 | <jgraham> | Also, "Feynman" is misspelt in the bio. If you are going to compare yourself to an intellectual luminary, you should at least try to get their name right :) |
| 10:55 | <jgraham> | annevk: XHR2 uses "subtract 0x20 from each byte" to do ascii case folding?! |
| 11:00 | <annevk> | jgraham, method is a sequence of octets at that point, not characters |
| 11:01 | <jgraham> | annevk: That makes no sense. Step 2 talks about code points. The same step talks about "case insensitive match" for a string |
| 11:03 | <annevk> | you can use case-insensitive for octets |
| 11:03 | <annevk> | also, step 2 turns method into a sequence of octets |
| 11:04 | <jgraham> | I don't see why you can do a case insensitive match and can't do case transformations |
| 11:05 | <jgraham> | Except for via direct manipulation of the values |
| 11:05 | <annevk> | presumably you can do case transformations, just nobody has that defined for octet sequences afaik |
| 11:05 | <MikeSmith> | Ms2ger: why bitbucket instead of github? |
| 11:06 | <jgraham> | OK, then my feedback is that you should find a way to either transform the case before the deflate or define what it means to case transform a sequence of bytes |
| 11:06 | <Philip`> | Because hg > git |
| 11:06 | <jgraham> | also hg < git. It is a funny algebra |
| 11:07 | <annevk> | not sure why I should do any of that |
| 11:08 | <jgraham> | Because the current spec relies on implicit knowledge of the layout of ascii to judge intent |
| 11:08 | <jgraham> | That's bad |
| 11:08 | <annevk> | HTML5 has that too iirc |
| 11:08 | <jgraham> | Well it's bad in HTML5 too then |
| 11:09 | <jgraham> | If you tell me where I will file a bug |
| 11:09 | <annevk> | e.g. http://www.whatwg.org/specs/web-apps/current-work/complete.html#concept-get-attributes-when-sniffing |
| 11:14 | <MikeSmith_> | speaking of github, http://es5.github.com/ is now multi-page |
| 11:14 | <jgraham> | MikeSmith: Oh, taht's sad |
| 11:14 | <MikeSmith_> | thanks to a repurposing of Philip` splitter |
| 11:14 | <jgraham> | I hope there is also a single page version |
| 11:14 | <jgraham> | and it is the default |
| 11:14 | <MikeSmith_> | jgraham: single-page is at http://es5.github.com/spec.html |
| 11:14 | <MikeSmith_> | hmm |
| 11:14 | <MikeSmith_> | OK, I guess I could make it the default |
| 11:15 | <jgraham> | The multipage version isn't very useful is it? |
| 11:15 | <jgraham> | I mean that page doesn't tend to kill browsers |
| 11:15 | <MikeSmith_> | matjas indicated otherwise |
| 11:15 | <MikeSmith_> | source is 1.5MB |
| 11:15 | <jgraham> | and the whole point of HTML in this context is to get proper search and hyperlinks |
| 11:15 | <MikeSmith_> | OK |
| 11:16 | <MikeSmith_> | so I can make the single-page the default again |
| 11:16 | <MikeSmith_> | until somebody suggests otherwise |
| 11:16 | <MikeSmith_> | would be good to hear what matjas thinks |
| 11:17 | <annevk> | http://platform.html5.org/ should probably link to the crypto stuff and abarth's URL API |
| 11:18 | <zcorpan> | is URL implemented? |
| 11:18 | <Ms2ger> | We're implementing |
| 11:19 | <MikeSmith> | what's the link for the URL API? |
| 11:19 | <MikeSmith> | annevk: you mean DOMCrypt? |
| 11:21 | <annevk> | I think it is https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1 |
| 11:23 | <annevk> | hmm, .isInDocument |
| 11:23 | <Ms2ger> | Oh, did smaug propose that? |
| 11:23 | <annevk> | it's fairly trivial to just check if the node is documentElement or an ancestor is |
| 11:24 | <annevk> | he mentioned it |
| 11:24 | <Ms2ger> | He's mentioned it before |
| 11:25 | <annevk> | MikeSmith, for XMLHttpRequest please link to the -2 edition |
| 11:25 | <MikeSmith> | OK |
| 11:25 | <Ms2ger> | "I think the PATCH method [1] should be supported in the XMLHttpRequest2 (section 4.6.1)." |
| 11:26 | <Ms2ger> | Use cases? What's that? |
| 11:26 | <MikeSmith> | annevk: and by crypto stuff did you mean DOMCrypt or the random-number thing? |
| 11:26 | <Ms2ger> | Both! :) |
| 11:27 | <annevk> | I think it would have been better if XHR uppercased all methods |
| 11:27 | <annevk> | but that's too much of a fork of HTTP reportedly |
| 11:27 | <annevk> | despite the fact that I don't think anyone will ever mint a lowercase method name at this point |
| 11:30 | <annevk> | btw, zcorpan, if you can figure out what exactly XHR should say with respect to garbage collection, I'd appreciate it |
| 11:33 | <zcorpan> | annevk: i'll have a look |
| 11:34 | <annevk> | you already filed two bugs, I'm now asking you to fix them :p |
| 11:34 | <annevk> | last time I took a look at the various sections in HTML I got very confused |
| 11:35 | <smaug____> | Ms2ger: annevk: so what do you think about isInDocument |
| 11:36 | <smaug____> | it would be trivial to add |
| 11:36 | <zcorpan> | annevk: one about navigation and the other about event handlers, right? |
| 11:36 | <smaug____> | and quite useful |
| 11:36 | <annevk> | smaug____, useful for what? |
| 11:37 | <annevk> | zcorpan, http://www.w3.org/Bugs/Public/show_bug.cgi?id=12837 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=12838 |
| 11:37 | <smaug____> | well, when handling some subtrees |
| 11:37 | smaug____ | needs to find some use case |
| 11:38 | <zcorpan> | heh, "The readyState attribute changes at some seemingly arbitrary times for historical reasons." |
| 11:41 | <matjas> | MikeSmith: yeah, the single-page variant froze my browser regularly |
| 11:41 | <MikeSmith> | matjas: ok |
| 11:41 | <matjas> | (thanks btw) |
| 11:41 | <MikeSmith> | np |
| 11:41 | <matjas> | I would be fine with it still being the default though |
| 11:41 | <MikeSmith> | ok |
| 11:41 | <MikeSmith> | will make that change now, then |
| 11:42 | <matjas> | anything to make jgraham happy! |
| 11:49 | <MikeSmith> | matjas: btw, chapter 15 is still a 600+ MB file |
| 11:49 | <erlehmann> | wat |
| 11:49 | <MikeSmith> | um, 600K |
| 11:49 | <MikeSmith> | I meant |
| 11:50 | <matjas> | phew ;) |
| 11:50 | <MikeSmith> | anyway, not surprising it's that big I guess |
| 11:50 | <MikeSmith> | I may tweak the splitter further to chop that up into smaller files |
| 11:50 | <jgraham> | matjas: So far today everything is conspiring to make me unhappy (more so than usual I mean), so I am greatful for small victories ;) |
| 11:50 | <MikeSmith> | jgraham: ok, default is now back to single-page |
| 11:50 | <matjas> | MikeSmith: this is chapter 15: http://i.imgur.com/HD83W.png :( |
| 11:51 | <MikeSmith> | matjas: point taken :) |
| 11:51 | <matjas> | needs moar splitting |
| 11:51 | <MikeSmith> | I will take a look at the splitter code now |
| 11:51 | <MikeSmith> | yup |
| 11:51 | <zcorpan> | annevk: it seems the spec fires the events in the same task as it changes readyState, which is great for specifying the gc policy |
| 11:52 | <jgraham> | MikeSmith: Thanks :) |
| 11:52 | <MikeSmith> | yup |
| 11:52 | <MikeSmith> | thanks for prodding me |
| 11:53 | <MikeSmith> | the splitter currently just splits on any <h2> but I guess a good tweak would to also have it split on anything that has a, say, class=splitme |
| 11:53 | MikeSmith | counts how many ch. 15 subsections he needs to add a class attribute to |
| 11:57 | <annevk> | zcorpan, cool I guess :) |
| 11:57 | annevk | wonders where Ms2ger went |
| 11:58 | <annevk> | I tried clarifying the goals of the DOM spec: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#goals |
| 11:59 | <annevk> | I hope that's clear enough for Microsoft |
| 12:08 | <MikeSmith> | matjas: OK, chapter 15 now split up too |
| 12:09 | <MikeSmith> | matjas: all the generated files are now less than 130K |
| 12:09 | <MikeSmith> | but if you have problems with any others, I can split some further |
| 12:11 | <matjas> | yay \o/ |
| 12:11 | <MikeSmith> | :) |
| 12:14 | <zcorpan> | annevk: ok now i need go through the sync case |
| 12:14 | <matjas> | seems like github-pages still haven’t been rebuilt fully |
| 12:15 | <Ms2ger> | annevk, seems like the HTML5 stuff doesn't really belong below (1) |
| 12:18 | <MikeSmith> | matjas: they have for me |
| 12:18 | <MikeSmith> | though I had to force-reload |
| 12:21 | <MikeSmith> | matjas: e.g., http://es5.github.com/x15.4.html |
| 12:21 | <matjas> | yeah works now |
| 12:21 | <MikeSmith> | ok |
| 12:21 | <matjas> | those URLs already worked but the links just wouldn’t show up, even after a force-reload |
| 12:22 | <matjas> | ¯\_(ツ)_/¯ |
| 12:23 | <annevk> | Ms2ger, good point |
| 12:23 | <annevk> | I'll add that as a separate point |
| 12:23 | <annevk> | 4 goals for DOM4 |
| 12:28 | <smaug____> | annevk: how does http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-types-list prevent anything? |
| 12:28 | <smaug____> | the table is marked non-normative |
| 12:30 | <annevk> | " if it is attached to the bubbling phase only, this event listener is required not be triggered" |
| 12:30 | <annevk> | DOM3 Events is hopelessly confusing, contradictory and full of holes |
| 12:30 | <annevk> | it's beyond me why it's being developed |
| 12:31 | <smaug____> | HTML spec is hopelessly confusing and full of holes :p |
| 12:32 | <annevk> | no it isn't |
| 12:32 | <smaug____> | and yet I think it is a reasonable thing to develop |
| 12:32 | <smaug____> | it is |
| 12:32 | <zcorpan> | annevk: ok commented on the GC bug. couldn't figure out if the sync case should be different or not |
| 12:32 | <zcorpan> | annevk: likely it's not quite right, too. needs review |
| 12:32 | <annevk> | smaug____, it's far more detailed and doesn't contain such glaring inaccuracies |
| 12:32 | <annevk> | thanks zcorpan |
| 12:39 | <bencc> | who is responsible to send keep-alives ping requests in websockets? the application code or the browser? |
| 12:40 | <annevk> | prolly app |
| 12:40 | <jgraham> | I thought the opposite |
| 12:41 | <annevk> | might have changed I guess, haven't followed anything recent |
| 12:42 | <bencc> | prolly app? |
| 12:42 | <bencc> | what is prolly? |
| 12:42 | <annevk> | slang for probably |
| 12:43 | <bencc> | ok. thanks |
| 12:43 | <jgraham> | Oh well the draft doesn't actually say anything. So who knows |
| 12:44 | <bencc> | the browser teams must know |
| 12:44 | <bencc> | because they either implement a ping or not |
| 12:44 | <jgraham> | Well not by reading the draft they won't |
| 12:45 | <bencc> | so it should be fixed |
| 12:45 | <bencc> | they probably don't handle it |
| 12:48 | <bencc> | how do I send a ping from the client side? |
| 12:49 | <jgraham> | AFAIK you can't |
| 12:50 | <zcorpan> | the API doesn't expose anything around pings/pongs |
| 12:50 | <zcorpan> | so teh app can't do anything with pings/pongs |
| 12:50 | <jgraham> | So presumably the browser is supposed to send them? |
| 12:50 | <zcorpan> | at least in the browser |
| 12:50 | <annevk> | zcorpan, will you do salvaging too? |
| 12:50 | <jgraham> | Or are we ignoring them? |
| 12:50 | <bencc> | how can the server knows how long to wait to find a dead connection? |
| 12:50 | <zcorpan> | annevk: yeah i'll look at that as well |
| 12:50 | <annevk> | zcorpan, also, for sync, can you even get into garbage collection? |
| 12:51 | <annevk> | zcorpan, while a sync operation is ongoing |
| 12:51 | <zcorpan> | annevk: sure |
| 12:51 | <annevk> | i guess if people close the browser? |
| 12:52 | <zcorpan> | or if the browser is running out of resources and wants to do a hard GC somewhere |
| 12:53 | <Ms2ger> | Oh look, D3E now has two automated tests |
| 12:53 | <annevk> | zcorpan, that particular scenario is out of scope typically |
| 12:55 | <annevk> | Ms2ger, can we change Anolis to just output the names of all authors in the references? or is that forbidden? |
| 12:55 | <zcorpan> | websocket talks about what to do if you GC an open websocket |
| 12:55 | <Ms2ger> | WFM |
| 12:55 | <Ms2ger> | Want to fix? :) |
| 12:56 | <annevk> | not now, but I can look into it I guess |
| 13:19 | <zcorpan> | "Act as if the user aborted the cancels the request."? wow, wonder how i ended up with that |
| 13:20 | <zcorpan> | hmm i guess i typed up to "aborted the", then looked up what the spec called it and then forgot to remove that part |
| 13:21 | <zcorpan> | annevk: possibly you need to have a way to kill an XHR without firing events, to use when navigating away |
| 14:28 | <timeless> | jgraham: i'd only bother if someone would accept my edits |
| 14:28 | <timeless> | otoh, if it were on bitbucket, i'd fork it and make a patch series and send a pull request |
| 14:33 | <timeless> | zcorpan: re websocket you can define a per app specific NOP/PING and then use .send() with it |
| 14:33 | <timeless> | bencc: interestingly enough, i had the same question yesterday |
| 14:33 | timeless | had poor connectivity and couldn't figure out where the current websocket protocol spec was |
| 14:34 | timeless | reaches now now |
| 14:37 | <zcorpan> | timeless: those would be data messages, not ping/pong frames |
| 14:42 | <timeless> | sure, data messages w/ app specific ping-pongs :) |
| 15:39 | <bencc> | sessionStorage is per browser tab and localStorage lasts between sessions |
| 15:39 | <bencc> | is there something in between? |
| 15:39 | <bencc> | I need to store data that all the tabs can access but I need it to be per session |
| 15:39 | <bencc> | like cookies are |
| 15:43 | <AryehGregor> | Shelley: "Just an opinion, but Aryeh, I think you need to have a chat with Google about your work with the W3C, because you seem to be confused about Google's relationship with the W3C and how it impacts on your work." |
| 15:43 | <AryehGregor> | My carefully calculated response: "The person at Google who oversees my work is Ian Hickson. If you think I misunderstand my work obligations, I advise you to take it up with him." |
| 15:45 | <jgraham> | My carefuly crafted response to Shelley would be "" |
| 15:45 | <jgraham> | Life is just too short |
| 15:46 | <AryehGregor> | Yeah, I have an excessively strong tendency toward http://xkcd.com/386/. |
| 15:51 | <annevk> | where did zcorpan go? |
| 15:51 | <annevk> | hmm |
| 15:51 | <annevk> | I think XMLHttpRequest garbage collection might need to be closer to EventSource than WebSocket |
| 16:00 | <annevk> | why does "make disappear" not apply to EventSource? |
| 16:01 | <AryehGregor> | specification Failed to load resource |
| 16:01 | <AryehGregor> | dfn.js Failed to load resource |
| 16:01 | <AryehGregor> | My spec now has no styling. |
| 16:03 | <annevk> | whatwg.org offline again? |
| 16:25 | <dglazkov> | good morning, Whatwg |
| 16:25 | <Ms2ger> | Evening |
| 16:25 | <annevk> | hi hi |
| 18:38 | <AryehGregor> | Is there some way to make text have a color that inverts whatever it lies on top of? I have some text that's absolutely positioned, and it sometimes obscures other text. I'd like the place where they overlap to become white instead of black, or something. |
| 18:38 | <AryehGregor> | Would I have to use an SVG filter or some craziness like that? |
| 18:39 | AryehGregor | figures he'll have to live with it overtyping for now |
| 18:39 | <shepazu> | AryehGregor: you could do it with Canvas, or with an SVG filter |
| 18:39 | <shepazu> | oh, wait |
| 18:39 | <shepazu> | I misread that |
| 18:40 | <shepazu> | I'd have to see an example, really |
| 18:40 | <AryehGregor> | foo<span style=position:absolute>{}</span>bar |
| 18:40 | <Ms2ger> | color: invert? |
| 18:40 | <AryehGregor> | That's the specific example I'm looking at. |
| 18:40 | <Ms2ger> | Or was that only for outline? |
| 18:41 | AryehGregor | doesn't see it as available in http://www.w3.org/TR/css3-color/ for color |
| 18:41 | <AryehGregor> | http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines |
| 18:41 | <AryehGregor> | Looks like only for outline. |
| 18:41 | AryehGregor | tries it with an outline |
| 18:44 | <AryehGregor> | Ah, but that outlines the whole box. |
| 18:44 | <AryehGregor> | Well, whatever. |
| 18:44 | <Ms2ger> | Though at least Gecko dropped support for that years ago |
| 18:46 | <Hixie> | AryehGregor: google's relationship with the w3c's impact on your work is nil, as far as i'm concerned |
| 18:47 | <AryehGregor> | Hixie, I realize. |
| 18:47 | <Hixie> | :-) |
| 18:47 | <Hixie> | though of course you can use your judgement in figuring out how to get feedback, get things implemented, etc |
| 18:47 | <Hixie> | (so long as you're not committing google to anything, obviously) |
| 18:48 | <AryehGregor> | Clearly. |
| 18:49 | <rniwa> | AryehGregor: are you aware of http://www.w3.org/community/editing/? |
| 18:49 | <AryehGregor> | rniwa, I created it. |
| 18:49 | <rniwa> | AryehGregor: ah ok |
| 18:49 | <rniwa> | AryehGregor: should I join that? |
| 18:49 | <AryehGregor> | If you like. I don't think the membership will matter. |
| 18:49 | <rniwa> | AryehGregor: ok |
| 18:50 | rniwa | likes to be in the loop |
| 18:50 | <AryehGregor> | I plan to use it for publishing the spec and nothing else, since we already have wikis/mailing lists/etc. and I don't want to fragment them. |
| 18:52 | <Hixie> | annevk: when you get back, see http://www.w3.org/Bugs/Public/show_bug.cgi?id=11204 |
| 19:49 | <manu-db> | Question about JavaScript APIs spec'd in WebIDL directed at anyone that knows the answer: |
| 19:49 | <manu-db> | When processing a part of a DOM or JSON, is it better to return a null value (if there was some sort of processing error), or is it better to raise an exception of some sort? |
| 19:50 | <manu-db> | and if it "depends on the application", are there general guidelines? |
| 19:52 | <AryehGregor> | manu-db, it depends, and partly it's a matter of taste. Exceptions cause the whole app to blow up if uncaught, so it's best to only throw them only if the author did something seriously wrong. Returning null or something is typically a better idea if there's nothing wrong with what the author did, but there's no useful information to return. |
| 19:52 | <Hixie> | (of course returing null if the author didn't expect it can quickly turn into an exception too) |
| 19:53 | <AryehGregor> | It would be easier to say if you gave a specific example. |
| 19:53 | manu-db | goes to find an example... |
| 19:53 | <manu-db> | http://json-ld.org/spec/ED/20110817/#widl-JSONLDProcessor-frame-object-object-input-object-frame-object-options-JSONLDProcessorCallback-callback |
| 19:53 | <manu-db> | bleh, that is an awful URL... |
| 19:54 | <Ms2ger> | Yes, I was about to mention that :) |
| 19:54 | <zewt> | returning null on an error condition isn't very useful--it doesn't say anything about what failed |
| 19:54 | <AryehGregor> | It really depends. |
| 19:55 | <manu-db> | anyway - the jsonld.frame() call takes a JavaScript object (input) and another JavaScript object (frame) and re-organizes the original input to have a specific structure/hierarchy (based on the frame). |
| 19:55 | <Ms2ger> | And what is the error condition you're thinking of? |
| 19:55 | <manu-db> | but there are some frames that are just plain invalid. |
| 19:55 | <manu-db> | (because keywords were messed up or data is wrong, etc.) |
| 19:55 | <AryehGregor> | manu-db, if designing a new API from scratch, I'd usually say to throw an exception if the method was passed invalid/malformed input. |
| 19:55 | <Ms2ger> | What he said ^ |
| 19:56 | <Hixie> | there are varying schools of thought. My main feedback would be that if you pick one, make sure to stick to it so that the API is consistent |
| 19:56 | <manu-db> | so, you could answer back with null, which means (you gave us crap... so your output is null) - or you could throw an exception (you gave us crap, your code is busted... fix it) |
| 19:56 | <Hixie> | and if people convince you to change from one to the other, make sure to change everything at the same time so it stays consistent :-) |
| 19:56 | <AryehGregor> | If the author is passing malformed input to the API, it almost certainly indicates some kind of bug. |
| 19:57 | <AryehGregor> | There's no reason you'd want to pass malformed input to this API, right? |
| 19:57 | <Hixie> | well it could be user-provided input |
| 19:57 | <Hixie> | right? |
| 19:57 | <manu-db> | AryehGregor - correct. |
| 19:57 | <Ms2ger> | Consistency is the hobgoblin of little minds. |
| 19:57 | <Hixie> | that you just didn't check |
| 19:57 | <zewt> | returning null for invalid input would be very unusual |
| 19:57 | <manu-db> | well, developer provided in this case. |
| 19:57 | <Philip`> | If the function just returned null, how would you tell what the error was in the input and how to fix it? |
| 19:57 | <AryehGregor> | Right, then you want to do try/catch. |
| 19:57 | <Hixie> | Ms2ger: so are cliches :-P |
| 19:57 | <manu-db> | I can't think of a use case where it would be user-provided, Hixie... |
| 19:57 | <AryehGregor> | Philip`, probably an exception would just be SYNTAX_ERR anyway. |
| 19:57 | <Ms2ger> | Hixie, indeed :) |
| 19:57 | <zewt> | to little minds, consistency is a hobgoblin |
| 19:58 | <AryehGregor> | manu-db, oh, so you'd expect that the correct use of the function would only be to accept input that comes from another function? |
| 19:58 | <Ms2ger> | AryehGregor, of course he should invent an exception hierarchy five levels deep |
| 19:58 | <AryehGregor> | Or that was typed manually by the developer? |
| 19:58 | <AryehGregor> | In that case, definitely throw. |
| 19:58 | <AryehGregor> | Invalid input indicates a bug. |
| 19:58 | <manu-db> | AryehGregor - correct. |
| 19:59 | <AryehGregor> | The only time I'd say not to throw on invalid input is if it's user-provided or something, so it might be invalid even if there are no bugs in the program. |
| 19:59 | <zewt> | should throw in that case too, IMO |
| 19:59 | <AryehGregor> | Yeah, I'd usually say to throw then too. |
| 19:59 | <AryehGregor> | But there's more of a case for not throwing, because it can cause the program to die. |
| 19:59 | <AryehGregor> | If you can handle it gracefully, that might be better. |
| 19:59 | <manu-db> | Ok, well - that was all very helpful - thanks AryehGregor, Hixie, Ms2ger, Philip`, zewt |
| 20:00 | <zewt> | the error result could do that in any case, if the programmer wasn't aware that it can happen |
| 20:00 | <manu-db> | I'll change the API to throw exceptions, consistently, on input that is a syntax error. |
| 20:00 | <AryehGregor> | E.g., per my current spec, execCommand() and friends only throw if you call a method on some command where it makes no sense, like asking for the value of bold. |
| 20:00 | <zewt> | at least, for things returning a value |
| 20:00 | <AryehGregor> | zewt, it depends what you return. If you're normally going to return an object, yes. If you're normally returning a string, probably not. |
| 20:00 | <AryehGregor> | Particularly not if you return an empty string on error instead of null. |
| 20:01 | <AryehGregor> | Basically, make it easy to gracefully handle user input errors. |
| 20:01 | <AryehGregor> | If possible. |
| 20:01 | <zewt> | just seems like a way of masking bugs and making them harder to fix |
| 20:01 | <AryehGregor> | zewt, not if the user input is uncommon or unreasonable anyway. E.g., at one point I had execCommand("insertImage", false, "") (= insert an image with no URL) throw. Now it just does nothing. |
| 20:02 | <AryehGregor> | Thus it has no effect, which makes sense, instead of crashing the program. |
| 20:02 | <AryehGregor> | That's a reasonable case of graceful error handling. Throwing wouldn't really help anyone. |
| 20:02 | <AryehGregor> | Since typically, the URL will be user-provided, and if the user provides the empty string as a URL for some reason, it's not helpful to crash. |
| 20:03 | <Philip`> | manu-db: By the way: "The 'input' is used to build the framed output and is returned if there are no errors." sounds like it's returning the 'input' value, which seems kind of redundant - is it meant to say it returns the framed output instead? |
| 20:03 | <AryehGregor> | Of course a well-designed app will validate the URL to a greater extent than that, but this helps out apps that were written without so much care. |
| 20:03 | <zewt> | that's not reporting an error with a mechanism other than exceptions (eg. returning it), though, that's just silently ignoring errors, which is different |
| 20:04 | <manu-db> | Philip` the prose is crap right now... gonna make another pass at cleaning it up. But yes, you are right - I'll try to make it more apparent that the input value is being used to generate /something else/ that will be returned by the method. |
| 20:04 | <Philip`> | AryehGregor: "crashing the program" seems misleading - more likely it'll just abort the onclick handler of the button the user clicked to insert an image, which isn't a particularly fatal problem |
| 20:04 | <AryehGregor> | Philip`, depends what the onclick handler is doing. |
| 20:05 | <AryehGregor> | zewt, yes, true. |
| 20:12 | <manu-db> | Got another question for anyone that knows how @lang or @xml:lang is processed in HTML5 across most of the browsers... Ivan reported a bug where the language of a document may not be properly detected if there is a bunch of stuff in the <HTML> element - for example if there are a ton of @xmlns: or @prefix declarations. It seemed as if some of the browsers sniff for the language of the... |
| 20:12 | <manu-db> | ...document, and if they don't find it in the first 256 bytes (or something like that), they just default to a western character set, which hoses the page. |
| 20:12 | <AryehGregor> | IIRC, charset detection isn't very standard right now. Browsers definitely do charset detection only based on the first handful of bytes, though. |
| 20:12 | <manu-db> | This came up because we were thinking of limiting @prefix declarations in RDFa 1.1 to the HTML element... but if this bug exists, we may want to allow @prefix on HTML, HEAD and BODY... instead of all elements. |
| 20:12 | <AryehGregor> | As a rule. |
| 20:13 | <AryehGregor> | So if they're using lang="" as part of charset detection, that can't be too far into the HTML source. |
| 20:13 | <AryehGregor> | Same with <meta charset> etc. |
| 20:13 | <manu-db> | damn... |
| 20:13 | <AryehGregor> | That's because they don't want to get the first packet, start parsing in one charset, then have to throw everything away and start over when they get the second packet. |
| 20:14 | Philip` | wasn't aware of browsers ever using lang for charset detection |
| 20:14 | <AryehGregor> | So they only look at a handful of bytes, which will hopefully be in the first packet. |
| 20:14 | <manu-db> | is there any effort to spec that in HTML5? This seems to be an issue in any non-western character-set HTML document. |
| 20:14 | <AryehGregor> | There's something about it, let me see. |
| 20:14 | <manu-db> | hmm... I see. |
| 20:14 | <Philip`> | HTML5 says to look in at least the first 1024 bytes for a charset, I think |
| 20:14 | <Ms2ger> | I doubt that browsers really use lang |
| 20:14 | <manu-db> | Problem is that it totally screws over the non-western charset people. |
| 20:15 | <Ms2ger> | Those who still don't use UTF-8? |
| 20:15 | <AryehGregor> | Basically, everyone should just use UTF-8, yeah. |
| 20:15 | <manu-db> | yeah |
| 20:15 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding |
| 20:16 | <manu-db> | Ms2ger yes it screws over the non-UTF-8 people... but there are quite a number of them (anecdotal) |
| 20:16 | <Ms2ger> | And if they insist on something else, there's still the HTPP header |
| 20:16 | <AryehGregor> | HTML5 seems not to mandate a specific number of bytes. |
| 20:16 | <AryehGregor> | "The user agent may wait for more bytes of the resource to be available, either in this step or at any later step in this algorithm. For instance, a user agent might wait 500ms or 1024 bytes, whichever came first." |
| 20:16 | <AryehGregor> | "Note: The authoring conformance requirements for character encoding declarations limit them to only appearing in the first 1024 bytes. User agents are therefore encouraged to use the preparse algorithm below (part of these steps) on the first 1024 bytes, but not to stall beyond that." |
| 20:17 | <AryehGregor> | The upshot is, though, you want to have <meta charset> or whatnot somewhere early in the page. |
| 20:17 | <AryehGregor> | Having it after lots of prefixes or whatever is definitely bad, it can cause problems. |
| 20:18 | <Philip`> | And you want to have HTTP content-type:text/html;charset=utf-8 so browsers don't have to sniff for the encoding at all |
| 20:18 | <AryehGregor> | Or a BOM or something, right. |
| 20:18 | <AryehGregor> | But <meta charset> early in the document is also fine. |
| 20:18 | <Philip`> | (Having a document specify its encoding in a way that you can only correctly read after decoding the document is a stupid idea :-( ) |
| 20:19 | <manu-db> | Philip` this is an issue with files on disk... no way to set Content-Type: |
| 20:19 | <AryehGregor> | Philip`, yeah, which is why there's a mini-parser to retrieve <meta charset> . . . |
| 20:19 | <The_8472> | how does that parser work? |
| 20:19 | <The_8472> | pushing the entire thing through a whole array of charset decoders? |
| 20:20 | <Philip`> | The_8472: It's a simplified version of the tokeniser algorithm that looks for meta elements with suitable attributes |
| 20:20 | <manu-db> | I'm trying to think of language that we could put in the RDFa Core 1.1 spec that would basically say: "If you want to publish conformant RDFa 1.1 - you should be using UTF-8 and you should be specifying the Content-Type:" |
| 20:20 | <Philip`> | and assumes the document is encoded in an ASCII-compatible way |
| 20:20 | <The_8472> | ah |
| 20:21 | <AryehGregor> | manu-db, note that in HTML5, any document with <meta charset> after the first 1024 bytes is already invalid. |
| 20:21 | <The_8472> | so utf-32 would break it |
| 20:21 | <Hixie> | utf-32 is strongly discouraged |
| 20:21 | <AryehGregor> | So presumably it's already invalid in HTML5+RDFa too. |
| 20:21 | <Ms2ger> | Hixie, just discouraged? |
| 20:21 | <jamesr> | is utf-32 implemented? |
| 20:21 | <manu-db> | We're attempting to constrain @prefix to the root element... and do so in a way that doesn't screw the character encoding detection in browsers. |
| 20:21 | <jamesr> | supported? |
| 20:22 | <Ms2ger> | Gecko dropped support IIRC |
| 20:22 | <Philip`> | I don't the use of UTF-8 is relevant (though it's a good idea anyway) - the default decoding would be win-1252, so UTF-8 is no better than any other encoding in terms of failed charset detection |
| 20:22 | <Philip`> | s//think/ |
| 20:22 | <Hixie> | "Authors should not use UTF-32" and "Support for UTF-32 is not recommended" |
| 20:23 | <AryehGregor> | manu-db, you can always use a BOM, if you're using UTF-8 or such. |
| 20:23 | <AryehGregor> | Although that can be annoying/confusing. |
| 20:23 | <manu-db> | So using a BOM would trigger a high confidence rating ("tentative") across all browsers? |
| 20:23 | <Philip`> | The_8472: UTF-16 would break it too, as would e.g. EBCDIC (which is the cause of security vulnerabilities in some web software) |
| 20:23 | <The_8472> | some editors don't deal well with it |
| 20:24 | <manu-db> | Is there anything else that we could use to trigger UTF-8 detection? |
| 20:25 | <manu-db> | scratch that last thing I said - it didn't make any sense... rewording... |
| 20:25 | <The_8472> | magic charset guessing algos |
| 20:25 | <The_8472> | but they are... well... magic. and need enough content to find something that's not ascii |
| 20:25 | <zewt> | charset guessing is always horrible, heh |
| 20:25 | <The_8472> | yeah |
| 20:26 | <zewt> | also browsers preferring the user's local charset as the default is horrible |
| 20:26 | <manu-db> | There are no attributes that the browser uses to influence its guess at character encoding?? |
| 20:26 | <zewt> | countless japanese pages i've hit that don't display correctly, because of not being able to guess it based on content, and it happening-to-work because the author was on a japanese system, changing the default |
| 20:27 | <zewt> | noticed less of that lately; whether due to browser improvements, pages improving or chance i don't know |
| 20:29 | <Philip`> | manu-db: You could always encourage people to write <!doctype html><html><meta charset=utf-8><html prefix=...> and rely on the parser to hoist the prefix attribute back onto the root element |
| 20:29 | <manu-db> | yikes - that sounds like a recipe for disaster :P |
| 20:30 | <Ms2ger> | Not at all, it's very well specified ;) |
| 20:30 | <Philip`> | A very well specified disaster |
| 20:30 | <manu-db> | true story |
| 20:30 | <AryehGregor> | manu-db, it does. It's called <meta charset>. |
| 20:30 | <AryehGregor> | Nobody put arbitrary-length attributes on <html> or <head> before, so it worked fine. |
| 20:30 | manu-db | wonders if it would be okay to say that all RDFa documents MUST be encoded in UTF-8... |
| 20:31 | <Philip`> | manu-db: I don't think that would solve any problems |
| 20:31 | <Philip`> | since browsers don't assume UTF-8 by default |
| 20:31 | <AryehGregor> | manu-db, you don't have to specify anything extra. Anything that has an encoding specification that browsers won't pick up should, in theory, be invalid already anyway. |
| 20:31 | <AryehGregor> | If it's not, that's a bug in HTML5. |
| 20:31 | <manu-db> | sorry, Philip` - I thought the next few releases of browsers were switching over to do that... |
| 20:31 | <AryehGregor> | So if someone does tons of prefixes and then <meta charset>, it's already invalid. |
| 20:32 | <AryehGregor> | We all wish we could do UTF-8 as default, but it would horribly break the web. |
| 20:34 | <manu-db> | This makes me sad - it means that we probably won't be able to limit @prefix to the root element (because others in the WG feel strongly about not screwing up the meta charset detection) |
| 20:34 | Philip` | wonders if prefixes really need to be on an element, rather than a <meta name=prefixes ...> (where you look up the first such meta element in the first head element of the document, in place of looking up the attribute on the root element) |
| 20:34 | <manu-db> | Philip` - we do that for the BASE element... and everybody hated having to pre-process the document for that... |
| 20:34 | <manu-db> | although, that's an idea that really hasn't had much time in the spotlight in the RDFa work... I'll raise it again on the next telecon. |
| 20:35 | <manu-db> | Philip` - one of the other issues is that RDFa works on all XML dialects, and this isn't a problem in those other XML dialects... just HTML, IIRC |
| 20:35 | <manu-db> | s/on/in/ |
| 20:35 | <manu-db> | (and XHTML) |
| 20:37 | <Philip`> | manu-db: Would it require more processing than the attribute, given that <html><body>millions of lines<html prefix=...> will put the prefix attribute on the root element in HTML5 parsers so you presumably need some way to deal with attributes changing later (even without scripting)? |
| 20:37 | <Ms2ger> | Philip`, rdfa-using authors don't do that |
| 20:39 | <Philip`> | Evil ones might |
| 20:39 | <Ms2ger> | You don't use rdfa, do you? |
| 20:39 | <manu-db> | We do have a large number of evil authors... wait... no, that's not true at all. |
| 20:39 | <manu-db> | I think that would be a tough sell, Philip` - it's not just RDFa-using authors - it's any authors. |
| 20:39 | <Ms2ger> | manu-db, that would imply you have a large number of authors ;) |
| 20:39 | <Philip`> | Ms2ger: Only when trying to break it :-) |
| 20:40 | <manu-db> | Ms2ger - :P - no response... troll feeding and all :) |
| 20:40 | Ms2ger | bows |
| 20:41 | <manu-db> | Philip` - telling them to jump through those kinds of hoops because of the way character encoding works in browsers is going to be confusing to authors. |
| 20:43 | <manu-db> | Does anybody have any hard numbers on the number of documents on the Web that are non-ASCII, non-UTF8 and are served up without any sort of character encoding information? |
| 20:43 | <AryehGregor> | A very significant percentage. |
| 20:44 | <Philip`> | http://philip.html5.org/data/charsets.html may be relevant |
| 20:44 | <Philip`> | and/or may be confusing |
| 20:45 | <MikeSmith> | manu-db: fwiw, thanks for being frank about the task-force idea |
| 20:46 | <MikeSmith> | manu-db: you continue to be wrong about one thing, though |
| 20:46 | <manu-db> | MikeSmith: np - just trying to be pragmatic. |
| 20:46 | Ms2ger | trolls: Just one? |
| 20:46 | <MikeSmith> | yep |
| 20:46 | manu-db | would like to point out that it's far more than one. |
| 20:47 | manu-db | peers at Ms2ger. |
| 20:47 | <Ms2ger> | Also, I managed to read "pragmatic" as "pedantic" somehow |
| 20:47 | <manu-db> | Well, don't keep me waiting, MikeSmith - I need to add it to my list :P |
| 20:47 | <MikeSmith> | manu-db: I mean, the in-hindsight contention that proceeding with publication of the microdata and HTML+rdfa drafts in parallel was a mistake |
| 20:47 | <MikeSmith> | it was not a mistake |
| 20:48 | <MikeSmith> | it was pretty much an inevitability, given the circumstances |
| 20:49 | <manu-db> | I do personally feel it was a mistake - meaning, the ideal path would have been for a number of us involved to work more closely with one another and get behind some unified approach. |
| 20:49 | <MikeSmith> | true of many things |
| 20:49 | <MikeSmith> | but the ideal path is usually not available |
| 20:50 | <MikeSmith> | and the fact is that microdata is not bad |
| 20:50 | <manu-db> | I think it could've been if everybody had been a bit less hard headed about working together. |
| 20:50 | <MikeSmith> | well, lots of blame to be spread around there |
| 20:51 | <manu-db> | right, and I'm not that interested in spreading blame - more interested in figuring out how to not make the same series of mistakes again (as a community) |
| 20:51 | <MikeSmith> | Hixie and Henri made their concerns known years ago |
| 20:51 | <MikeSmith> | and they were largely blown off |
| 20:51 | <manu-db> | and so did we... |
| 20:51 | <manu-db> | and I disagree that they were blown off - I made it a point to discuss their issues in the RDFa 1.1 group... it was a focus. |
| 20:52 | <MikeSmith> | you did, yeah |
| 20:52 | <manu-db> | I know there is this belief that we didn't... but we spent a very long time discussing the concerns. |
| 20:52 | <MikeSmith> | you |
| 20:52 | <MikeSmith> | others did not |
| 20:52 | <AryehGregor> | IMO, this is a case where people just were going to disagree in the end, and the only way to move forward was to have two approaches and see how it went. I don't think any compromise would have been acceptable to all the key people. |
| 20:52 | <AryehGregor> | I definitely don't think it's worth rehashing at this point. |
| 20:52 | <manu-db> | A compromise would have been acceptable to me - and many others. (just for the record) |
| 20:52 | <manu-db> | anyway - we have what we have now... |
| 20:53 | <manu-db> | let's see how the market responds |
| 20:53 | <MikeSmith> | it's worth rehashing in order to make sure we all don't waste massive amounts of time repeating the same mistakes again |
| 20:53 | <manu-db> | Prediction: confusion, followed by taking sides, followed by a long-drawn out back and forth and finally, one comes out successful. |
| 20:54 | <manu-db> | I think the core of the rift had to do with the old XHTML2 vs. HTML5 stuff carrying over into the RDFa work. |
| 20:54 | <MikeSmith> | I think it remains unclear whether authors and content providers will ever on a large scale take time to mark up their content with any additional semantic markup at all |
| 20:54 | <manu-db> | and having not had anything to do with the XHTML2 stuff, the new folks in the RDFa work were kinda thrown into this mess that goes back 10+ years. Lots of bad blood in the Web standards game... most of which the new folks don't care one bit about... but keep getting smacked in the face with it. |
| 20:55 | <manu-db> | MikeSmith: I agree - I don't think anyone in the RDFa group believes that just because the spec exists that people are going to suddenly care about data. |
| 20:55 | <manu-db> | The whole semantics in HTML bit is what we're trying now because the "publish your data in a separate file" bit wasn't working. |
| 20:56 | <manu-db> | and really, people do this sort of stuff because there is something in it for them - SEO is the first carrot. |
| 20:56 | <Hixie> | tim does, or at least wouldn't acknowledge that they might not a few years ago when i spoke to him about it |
| 20:56 | <manu-db> | and perhaps the Web Payments stuff will be the second carrot. |
| 20:56 | <manu-db> | Hixie: TimBL thinks what? (I didn't follow) |
| 20:56 | <MikeSmith> | XHTML2 was a very big turn in the wrong direction -- as was the whole XHTML modularization focus. Anybody who still doesn't realize that, well, it's hard to have a discussion with them |
| 20:57 | <Hixie> | tim thinks people are going to use semantic markup in their output |
| 20:57 | <Hixie> | and that it'll be usable by tools |
| 20:57 | <Hixie> | i.e. that it won't be like existing markup, which is 90% syntactically invalid and semantically dubious |
| 20:57 | <manu-db> | MikeSmith - yes, and I'm one of those people that is happy about the HTML5 stuff winning out - but keep getting treated as if we're all still gung-ho about XHTML2 (which I'm not - but do appreciate the work that was done on that stuff as well) |
| 20:58 | <manu-db> | Hixie: I'm less certain about it - I don't know what will happen... I'm very bad at predicting the future. I think it's an idea worth trying, however... because if people /do/ start publishing more data - some of it may be very useful for the future of the Web. |
| 20:59 | <manu-db> | We're specifically interested in it because we had no other way to make PaySwarm truly decentralized... |
| 20:59 | <manu-db> | http://manu.sporny.org/2011/better-world/ |
| 20:59 | <manu-db> | (Building a Better World with Web Payments) |
| 20:59 | <Hixie> | i'm just saying that when you say "I don't think anyone in the RDFa group believes that...", my experience is that you are wrong |
| 20:59 | <manu-db> | RDFa is a means to an end for us... |
| 21:00 | <MikeSmith> | manu-db: you are exceptional in a lot of ways. If more people involved in this took the approach you have, we'd be a lot further along |
| 21:00 | <Hixie> | (at least for a definition of "RDFa group" that includes prominent people like tim) |
| 21:00 | <manu-db> | Hixie: I've never heard any of them say that they believe that the future is definitely going to be data in pages... |
| 21:00 | <Hixie> | then you haven't been listening :-) |
| 21:00 | <manu-db> | Hixie: but we do want that to happen... we're just not sure it will happen because it's up to the authors and CMSes now. |
| 21:01 | <Hixie> | we haven't even gotten people to use html correctly on any sort of widespread basis |
| 21:01 | <manu-db> | I don't include TimBL in the RDFa group... I was being more precise - the RDFa WG members that show up to all the calls. |
| 21:01 | <manu-db> | Hixie: I think HTML usage has been getting better over the years... people now care more about standards than they ever have. |
| 21:01 | <Hixie> | so the idea that they'll do something even more complicated than html, like microdata, with any sort of consistency or accuracy is imho wildly optimistic |
| 21:02 | <Hixie> | manu-db: do you have data backing that up? |
| 21:02 | <manu-db> | If you don't believe that, then I don't know why you're doing what you do. :) |
| 21:02 | <Hixie> | what do you think we're doing? |
| 21:02 | <manu-db> | No, I don't have hard data - just anecdotal evidence about what people are writing about online and conversations I have with web development firms over the past 10+ years. |
| 21:03 | <manu-db> | Hixie: Who is "we"? I was talking about /you/ :) |
| 21:03 | <manu-db> | That is not to say that people don't get stuff wrong... |
| 21:04 | <manu-db> | but there is a greater "moral pressure" to get things right now than there was in the late 1990s. |
| 21:04 | <Hixie> | ok what do you think I'm doing? |
| 21:04 | <AryehGregor> | Look, is this discussion really any different from the ones everyone has been having for the last few years? Do you think it's really going to be more useful this time than every time before? |
| 21:05 | <Hixie> | i think the moral pressure you're seeing is biased by the circles you go in. I've seen no actual evidence that people are using HTML more correctly than than 5, 10, or 15 years ago |
| 21:05 | <AryehGregor> | It's the same people making basically the same arguments over and over again. Let's just wait and see who's right. |
| 21:05 | <manu-db> | I think you're spec'ing what people practice online. |
| 21:05 | <manu-db> | and you're attempting to do it in a way that is consistent across all browsers. |
| 21:06 | <manu-db> | (even if the practice is bad) |
| 21:06 | <Hixie> | then why is what i said above a factor in why i do what i do? |
| 21:06 | <manu-db> | (and that happens in very few of the cases) |
| 21:06 | Philip` | guesses perceived XML-related gunghosity may be because RDFa dragged in a load of XML baggage from Namespaces (and partly Canonicalisation via XML literals etc), as well as from RDF itself, so most of the discussion was about problems and complexity induced by those things rather than by the interesting functionality of RDFa |
| 21:07 | <manu-db> | "what I said" - what specifically are you referring to? |
| 21:08 | <manu-db> | (because you said a number of things above) |
| 21:08 | <Hixie> | I said "so the idea that they'll do something even more complicated than html, like microdata, with any sort of consistency or accuracy is imho wildly optimistic" and you said "If you don't believe that, then I don't know why you're doing what you do." but I don't see why |
| 21:09 | <manu-db> | My statement wasn't in response to what you wrote on the line above |
| 21:09 | <Hixie> | oh |
| 21:09 | <Hixie> | what was it in response to? |
| 21:09 | <manu-db> | I think HTML usage has been getting better over the years... people now care more about standards than they ever have... If you don't believe that, then I don't know why you're doing what you do. |
| 21:10 | <Hixie> | people as in authors or people as in browser vendors? |
| 21:10 | <manu-db> | ^^^ All I was saying is that I think you think the work that you're doing is having a positive impact - otherwise you wouldn't be doing it... so your belief is that things are getting better. |
| 21:10 | <manu-db> | or, you're a masochist. :P |
| 21:10 | <Ms2ger> | Or both |
| 21:11 | <manu-db> | XOR |
| 21:11 | <Hixie> | even if authors entirely ignored the spec, i would still think it's important to have a single spec so that browsers can converge on interoperable behaviour |
| 21:11 | <Hixie> | (in fact, i think authors by and large do entirely ignore the spec) |
| 21:11 | <manu-db> | I don't think they do - I think there is a bias when you see errors... to only see the errors and not the sea of things that are being done correctly out there. |
| 21:12 | <Hixie> | there's no bias. I've done actualy objective studies on the google search corpus. |
| 21:12 | manu-db | wishes those studies were available to the public. |
| 21:12 | <Hixie> | looking to see what percentage of pages have conformance errors |
| 21:12 | <Philip`> | (Validator developers don't ignore the spec and a non-negligible number of authors don't ignore validators, so I'd assume that's how the spec most influences authors) |
| 21:12 | <manu-db> | I don't think just looking at conformance errors are interesting... I think the type of conformance errors are very important. |
| 21:13 | <Hixie> | Philip`: right |
| 21:13 | <manu-db> | exactly, Philip` |
| 21:13 | <Hixie> | manu-db: well, you're welcome to do your own studies like Philip` has :-) |
| 21:13 | <Hixie> | but i have not seen any evidence that things are changing |
| 21:13 | <Philip`> | (which incidentally means the non-machine-checkable conformance requirements are a waste of everyone's time) |
| 21:13 | <Hixie> | and i don't see why that would affect whether i do this work |
| 21:13 | <manu-db> | Yeah - we really do need public data on this. |
| 21:14 | <manu-db> | That's why I'm pursuing this deal w/ this Web crawl company - so we can get some of this data out in the public and start making more data-driven decisions. |
| 21:14 | <Philip`> | Getting reliable data for a single moment in time is hard enough - trying to compare it over years seems pretty much impossible :-( |
| 21:14 | <Philip`> | Any real changes will be drowned out by sampling biases |
| 21:15 | <Philip`> | (assuming it was even possible to get historic samples) |
| 21:15 | <manu-db> | Philip` but it's one of the only ways we can stop these ridiculous "I think X" ... "Oh yeah, well I think Y" discussions |
| 21:15 | manu-db | wonders if you could crawl the Internet archive for historical samples? |
| 21:16 | <manu-db> | I really think that we should be doing this sort of data collection as a community... anyway - working on it. |
| 21:16 | <Philip`> | Yeah, some data is still better than no data :-) |
| 21:16 | <manu-db> | Hixie - I trust that you have done the background research - but without having the data publicly available, it's not science. |
| 21:16 | <manu-db> | and I have no idea why Google wouldn't agree to release those figures publicly. |
| 21:17 | <Hixie> | manu-db: i don't think anyone would claim this was science |
| 21:17 | <manu-db> | There are good bits of Microformats, Microdata and RDFa that are witchcraft - no solid data behind the decisions. |
| 21:18 | <manu-db> | Hixie: I don't think it would hurt us to go more toward science than witchcraft. :) |
| 21:18 | <Hixie> | well sure |
| 21:18 | <Hixie> | that's up to the people doing the language design |
| 21:18 | <manu-db> | I think it's up to the community, not just the handful of people doing language design. |
| 21:19 | manu-db | has to run to a telecon. |
| 21:20 | <manu-db> | Good chat - thanks all for answering those two questions... much appreciated. |
| 22:50 | <AryehGregor> | The fact that we have LLVM-to-JavaScript compilers that work in practice and are efficient enough to use for real-world applications is somehow terrifying: https://github.com/kripken/emscripten/wiki |
| 22:51 | <AryehGregor> | Like a speech synthesizer. Written in C++, compiled to LLVM, recompiled to JavaScript, actually runs in a web browser. |
| 22:51 | <AryehGregor> | It actually works. http://syntensity.com/static/espeak.html |
| 22:51 | AryehGregor | boggles |
| 22:52 | <Philip`> | It's possible to write code and run it on a computer? Amazing! |
| 22:53 | <AryehGregor> | "The development versions of the top JavaScript engines today can run code compiled from C++ only 3-5X slower than a fast C++ compiler, and getting even better." |
| 22:53 | <David_Bradbury> | Any ideas if CSS3 gradients will be able to be used on boarders down the road? |
| 22:53 | <zewt> | ... uh huh |
| 22:53 | <AryehGregor> | David_Bradbury, TabAtkins is the one to ask about that. |
| 22:54 | <roc> | depends on how you want to use them |
| 22:54 | <David_Bradbury> | Kk - TabAtkins: Any ideas if CSS3 gradients will be able to be used on boarders down the road? :D |
| 22:54 | <roc> | current CSS3 drafts already let you use gradients with border-image |
| 22:54 | <roc> | although Gecko at least doesn't support that yet AFAIK |
| 22:55 | <David_Bradbury> | Don't you have to use an actual pre-rendered image to do that or can you use an ID or something as an image? |
| 22:55 | <TabAtkins> | David_Bradbury: In border-image. |
| 22:55 | <TabAtkins> | David_Bradbury: No, border-image just takes an image. |
| 22:55 | <TabAtkins> | Anything which is defined as part of the <image> type, theoretically. |
| 22:55 | <AryehGregor> | But doesn't border-image require an image in a very particular format? |
| 22:55 | <TabAtkins> | No. |
| 22:56 | <David_Bradbury> | Well, I mean I could use an image to do a background gradient on a div |
| 22:56 | <David_Bradbury> | the point of having an api that allows you to do it is so that you don't need to do that |
| 22:56 | <AryehGregor> | I mean, you have to provide one single image for all four borders and then slice it up somehow, no? |
| 22:56 | <AryehGregor> | You can't use different images for different sides, say. Or could you fake it by just using complicated gradients with a bunch of extra stops? |
| 22:56 | <David_Bradbury> | No, you can use a single image using border-image |
| 22:57 | <roc> | yeah that's why I said it depends on *how* you want to use a gradient on the border |
| 22:57 | <annevk> | jamesr, UTF-32 is verboten :p |
| 22:57 | <roc> | some uses could be done with border-image:linear-gradient or border-image:radial-gradient; others can't |
| 22:57 | <David_Bradbury> | but it seems silly to have to use an image for a gradient border if you're going to allow people to define gradients as backgrounds |
| 22:58 | <jamesr> | annevk: it's not a terrible encoding for some things, actually |
| 22:58 | <roc> | yes it is |
| 22:58 | <jamesr> | annevk: constant-time indexing for the full range of unicode codepoints |
| 22:58 | <roc> | what are the use-cases for constant-time indexing? |
| 22:58 | <jamesr> | if you have a lot of codepoints that are 2^17th and larger it's better than utf-16 |
| 22:58 | <roc> | David_Bradbury: you need to describe what effect you're trying to get |
| 22:59 | <jamesr> | on the web it's useless |
| 22:59 | <David_Bradbury> | A one-pixel linear gradient as a boarder? |
| 22:59 | <David_Bradbury> | border* |
| 22:59 | <AryehGregor> | David_Bradbury, in theory, you can use gradients anywhere you can use images, as I understand it. |
| 22:59 | <TabAtkins> | Firefox has the non-standard border-colors property. |
| 22:59 | <TabAtkins> | So you can manually implement a gradient. |
| 23:00 | <AryehGregor> | jamesr, you basically never actually need constant-time code-point-based indexing, though. Either you're iterating through the whole string, or you can use byte-based indexing instead. |
| 23:00 | <David_Bradbury> | I guess I mean to ask if there is something planned in the spec down the road |
| 23:00 | <annevk> | jamesr, you still don't get all characters |
| 23:00 | <annevk> | jamesr, well, compound characters or whatever they are called |
| 23:00 | <David_Bradbury> | Hi davidb, I'm David B. |
| 23:01 | <davidb> | hi David_Bradbury |
| 23:02 | <jamesr> | annevk: surrogate pairs? those only exist in utf-16 |
| 23:02 | <jamesr> | annevk: all unicode codepoints are less than 2^22 or 2^23, so they all take the same space in utf32 |
| 23:02 | <jamesr> | none of this is important for the web so forget i asked :) |
| 23:03 | <TabAtkins> | annevk: jamesr is right. In utf-32 you just store the codepoint directly. |
| 23:03 | <jgraham> | jamesr: I suspect annevk means glyphs that are formed froma character plus a combining character |
| 23:04 | <jgraham> | So constant time indexing of codepoints doesn't give you constant time indexing of anything users care about |
| 23:08 | <annevk> | jamesr, no, diacritical marks as separate codepoints |
| 23:08 | <annevk> | yeah, what jgraham said |
| 23:09 | <annevk> | UTF-16 is nonsense too |
| 23:09 | <annevk> | but we cannot kill it |
| 23:09 | <annevk> | it's baked into fricking ECMAScript and the DOM :( |
| 23:09 | <annevk> | maybe fricking baked* |
| 23:09 | <zewt> | utf-16 is great: it takes the advantages of utf-8 and the advantages of a fixed-width encoding like ucs4 ... then throws them away and keeps the disadvantages of both |
| 23:10 | <jamesr> | annevk: UCS-2 is baked in |
| 23:10 | <jamesr> | ECMAScript has basically no UTF16 support |
| 23:10 | <jamesr> | if it has any |
| 23:10 | <jamesr> | surrogate pairs = you deal with it, sucker |
| 23:13 | <jamesr> | fromCharCode() and codePointAt() only handle codepoints <= 2^16 |
| 23:13 | <annevk> | that's kind of what I meant |
| 23:13 | <annevk> | but I should have said 16-bit code units |
| 23:23 | <gsnedders> | jamesr: {decode,encode}URL{Component,} deals with surrogates! But I think that's it. |
| 23:24 | <gsnedders> | Harmony will introduce some sort of support for full Unicode. |
| 23:27 | <kennyluck> | oh really, that sounds interesting. |
| 23:28 | <annevk> | hmm something is going wrong with the tracker again |
| 23:29 | <annevk> | oh oops |
| 23:29 | <annevk> | I had unchecked "Show editorial changes" |
| 23:29 | <Hixie> | should add something somewhere that says "23 editorial changes hidden" |
| 23:31 | <annevk> | yeah, or attempt to kill that option again over zcorpan's objections :p |
| 23:32 | <annevk> | Hixie, btw, what is the difference between EventSource and WebSocket when it comes to garbage collection? |
| 23:32 | <annevk> | Hixie, WebSocket is way more complicated |
| 23:33 | <Hixie> | the main difference is that websockets speak back to the host |
| 23:34 | <Hixie> | also maybe eventsource is buggy? doesn't look like it preserves the object for load/error events... |
| 23:34 | <annevk> | e.g. only WebSocket has "make disappear" steps |
| 23:35 | <annevk> | EventSource talks about a strong reference instead |
| 23:35 | <annevk> | maybe EventSource was done and then later you decided upon another way of doing this? |
| 23:36 | <annevk> | I'll file a bug on EventSource so you can take a look, let me know, and maybe I can then finally update XMLHttpRequest |
| 23:36 | <Hixie> | the make disappear stuff is entirely because websocket speaks back |
| 23:37 | <Hixie> | whereas eventsource is just a one-way connection |
| 23:37 | <Hixie> | websockets has a closing handshake, etc |
| 23:38 | <annevk> | well eventsource has a request and response |
| 23:38 | <Hixie> | yeah but it's http, so the connection can just be dropped arbitrarily |
| 23:38 | <Hixie> | whereas websocket has this closing handshake thing |
| 23:38 | <annevk> | okay |
| 23:38 | <annevk> | so XHR should be modeled after EventSource |
| 23:39 | <annevk> | I'll file a bug on the other events |
| 23:51 | <annevk> | haha http://imgur.com/xFfzw |
