| 00:53 | <othermaciej> | I am curious what is up with this RDFa issue |
| 00:53 | <othermaciej> | why so much sudden cross-list drama? |
| 00:53 | <othermaciej> | is it something I can safely ignore? |
| 06:24 | <zcorpan_> | annevk: "HTTP is in fact still restricted to a very limited character that can do only slightly more than US-ASCII." - something's missing after 'character' |
| 06:25 | <karlcow> | set |
| 06:44 | <Hixie> | HTTP supports a character _set_ other than the first 128 characters in Unicode? |
| 06:44 | <Hixie> | huh |
| 06:46 | <zcorpan_> | Hixie: isn't iso-8859-1 both a character set and encoding? |
| 06:46 | <Hixie> | yes, but does http support -1? |
| 06:47 | <zcorpan_> | dunno :) |
| 06:47 | <annevk3> | hmm, is this fallout from my blogpost? |
| 06:48 | <zcorpan_> | yes |
| 06:48 | Hixie | looks to see if you blogged :-) |
| 06:48 | annevk3 | just arrived in a Nikko |
| 06:48 | <annevk3> | s/a// |
| 06:48 | <zcorpan_> | you rrived in a Nikko? |
| 06:49 | <Hixie> | btw fwiw my understanding is that utf-16 actually isn't a good character encoding internally either |
| 06:49 | <annevk3> | in Nikko, small place outside Tokyo |
| 06:49 | <annevk3> | Hixie, I covered that |
| 06:50 | annevk3 | should go someplace rather than talking about this |
| 06:52 | <karlcow> | /kick annevk3 |
| 06:53 | <Hixie> | annevk3: before you go |
| 06:53 | <Hixie> | i'd be interested in people's feedback on the way i did author-facing DOM documentation: |
| 06:53 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#htmlcollection |
| 06:54 | <Hixie> | comes after each idl block in section 2 right now |
| 06:54 | <Hixie> | i'm planning on styling it a bit |
| 06:55 | <Hixie> | also in http://www.whatwg.org/specs/web-apps/current-work/#url-decomposition-attributes |
| 06:56 | <annevk3> | looks good |
| 06:56 | <Hixie> | cool |
| 06:56 | <Hixie> | when you get back examine the styles i'll come up with an let me know what you think :-) |
| 06:58 | <zcorpan_> | Hixie: are you going to add classes to everything that says which classes of products a piece of text applies to? |
| 06:58 | <Hixie> | no |
| 06:58 | <zcorpan_> | so what's the plan? :) |
| 06:58 | <Hixie> | i plan to have one class |
| 06:59 | <Hixie> | "impl" |
| 06:59 | <zcorpan_> | ah |
| 06:59 | <Hixie> | which hides stuff that authors might not want to see on first blush |
| 06:59 | <Hixie> | i've actually already marked up everything in sections 1 and 2 |
| 06:59 | <Hixie> | here let me add a quick alt style sheet |
| 07:02 | Hixie | tries to find a browser that actually supports alternative tyle sheets set from <Style> |
| 07:02 | <Hixie> | sigh |
| 07:02 | <zcorpan_> | doesn't firefox? |
| 07:02 | <Hixie> | apparently not |
| 07:02 | <zcorpan_> | hmm i thought it did before |
| 07:02 | <Hixie> | oh wait |
| 07:03 | <Hixie> | i have to regen the spec |
| 07:03 | <Hixie> | duh |
| 07:03 | <Hixie> | <-- idiot |
| 07:03 | zcorpan_ | modified the style sheet in view source |
| 07:03 | zcorpan_ | loves that feature |
| 07:05 | <Hixie> | oh dear, webkit just applies all these style sheets |
| 07:05 | <Hixie> | sigh again |
| 07:05 | <zcorpan_> | i think that's what opera does, too, and is correct per html4 iirc :) |
| 07:06 | <Hixie> | that's not clear |
| 07:06 | <Hixie> | but anyway |
| 07:06 | <Hixie> | html5 says otherwise! |
| 07:06 | <zcorpan_> | indeed |
| 07:06 | <Hixie> | ok well anyway |
| 07:06 | <Hixie> | style sheet should be there now |
| 07:06 | <Hixie> | it makes section 2 quite short! |
| 07:10 | <zcorpan_> | nice |
| 07:15 | <zcorpan_> | maybe .impl should be highlighted in some way by default: not only is it stuff that authors *don't* want to see, but it's also what implementors are specifically looking for |
| 07:16 | <Hixie> | some of the .impl stuff is individual words in the middle of paragraphs |
| 07:16 | <Hixie> | i don't want to add yet more confusing colours |
| 07:16 | <Hixie> | it's already going to be pretty confusing |
| 07:20 | <zcorpan_> | Hixie: parts of the ToC is broken with the author style sheet |
| 07:20 | <Hixie> | yeah i haven't updated the toc script to delete bits that are in the author sections yet |
| 07:20 | <Hixie> | er |
| 07:20 | <Hixie> | impl sections |
| 07:29 | <Hixie> | zcorpan_: i added another style sheet to highlight the impl bits |
| 08:20 | <Hixie> | zcorpan_: ok, toc updates too now |
| 08:24 | <zcorpan_> | Hixie: sweet |
| 08:26 | zcorpan_ | ponders whether 1.7.1 How to read this specification applies to authors |
| 08:27 | <Hixie> | yes |
| 08:33 | <zcorpan_> | Hixie: hmm, i'm thinking about the order of the subsections in 2.4 Common microsyntaxes -- in particular i think it would be useful to have boolean attributes and enumerated attributes next to each other and highlight that e.g. contenteditable is not a boolean attribute |
| 08:33 | <Hixie> | good call. file a bug? |
| 08:33 | <zcorpan_> | ok |
| 08:33 | <Hixie> | thanks! |
| 08:33 | <Hixie> | i want to have as few edits in this next checkin as possible |
| 08:33 | <Hixie> | it's gonna be huge enough as it is |
| 08:35 | <zcorpan_> | despite being only an editorial checkin, it will probably be one of the most useful checkins |
| 08:35 | <Hixie> | wtf i'm getting 500ms pings to my isp |
| 08:36 | <Hixie> | zcorpan_: it's including a lot of new text in the form of these dom overview bits |
| 08:36 | <zcorpan_> | Hixie: but those are still "editorial", are they not? |
| 08:37 | <Hixie> | yup |
| 08:37 | <Hixie> | they count as notes |
| 08:37 | Hixie | stops the three video downloads that were killing his connection |
| 08:38 | <zcorpan_> | downloading porn while doing work? |
| 08:39 | <Hixie> | downloading the dilbert animated series from iTunes |
| 08:43 | <zcorpan_> | Hixie: hmm. the links in the idl are broken in the author view |
| 08:43 | <Hixie> | yup |
| 08:43 | <Hixie> | dunno what to do about that |
| 08:44 | <zcorpan_> | maybe the author notes and ua requirements could be interleaved? |
| 08:45 | <Hixie> | how would that work, e.g., for the url decomposition attributes? |
| 08:45 | <Hixie> | also, that wouldn't actually solve the problem |
| 09:02 | <Hixie> | oooh, new top gear. i missed the start of the season. |
| 09:12 | <john_fallows> | Hixie: just reading through the latest spec draft and noticed a few things... |
| 09:13 | <john_fallows> | descriptions for onopen, onmessage and onerror still use "bubbling" in the language even though EventSource is not an element - is that still accurate? |
| 09:13 | <othermaciej> | Hixie: I just read your big thread with Sam on www-archive from earlier in the month |
| 09:13 | <othermaciej> | "Moving past last call for HTML5" |
| 09:14 | <othermaciej> | why is it that reading it feels like watching an elaborate kabuki dance? |
| 09:14 | <Hixie> | john_fallows: technically yes, though it's pretty much meaningless since it's not a DOM node anymore |
| 09:14 | <Hixie> | john_fallows: but i use the same terminology everywhere for consistency, and it is technically correct |
| 09:15 | <john_fallows> | okay - just checking because at first it seemed like an oversight |
| 09:15 | <Hixie> | though come to think of it, DOM3 Events might need to explicitly talk about event dispatch on non-nodes |
| 09:15 | <Hixie> | john_fallows: understood |
| 09:15 | <john_fallows> | on a different note: WebSocket authentication... |
| 09:16 | <Hixie> | othermaciej: which parts in particular? |
| 09:16 | <john_fallows> | saw that auth headers and cookies can be sent now, cool. |
| 09:16 | <Hixie> | john_fallows: yeah. not sure exactly how that's gonna work, but in theory it can |
| 09:16 | <john_fallows> | but there was also a note previously with a TODO for status code 401 |
| 09:16 | <john_fallows> | now 401 would fail the connection, right? |
| 09:16 | <Hixie> | yeah i decided to punt on that for this version |
| 09:17 | <john_fallows> | so auth would require an explicit preflight? |
| 09:17 | <Hixie> | it's require headers in the original connection, yeah. which probably isn't really possible to set up at this point. |
| 09:17 | <Hixie> | though if you websocket to the http port, you'll send cookies |
| 09:17 | <Hixie> | so you can use cookies |
| 09:18 | <Hixie> | if you set them ahead ahead of time |
| 09:18 | <Hixie> | set them up, even |
| 09:18 | <othermaciej> | Hixie: a lot of it sounded to me like he wanted something that he wasn't clearly coming out and saying |
| 09:18 | <john_fallows> | right, so preflight over regular http, possibly get a 401 for that, ensure the session cookie is setup, then make the WebSocket connection (with auth) ? |
| 09:18 | <othermaciej> | I guess he made some specific requests at the end but they seemed underwhelming relative to the build-up |
| 09:19 | <othermaciej> | was weird to read |
| 09:19 | <Hixie> | othermaciej: yeah it is still pretty unclear to me how he intends to declare consensus |
| 09:19 | <Hixie> | othermaciej: he never really answered that |
| 09:19 | <Hixie> | john_fallows: well typically cookie auth doesn't involve 401s, but yes |
| 09:19 | <othermaciej> | it seems clear to me that we can't have unanimity on everything, and while the W3C PRocess says that consensus is not unanimity, it doesn't make very clear how it differs |
| 09:20 | <Hixie> | othermaciej: there are topics where as far as i can tell we have people with mutually exclusive opinions |
| 09:20 | <Hixie> | othermaciej: so unanimity is impossible |
| 09:20 | <john_fallows> | Hixie: sure (possibly 401) :-) |
| 09:20 | <othermaciej> | I did find one interesting idea in the mail on www-archive, which is the idea of removing document conformance requirements |
| 09:20 | <othermaciej> | I wonder how many controversial issues that would take off the table |
| 09:21 | <Hixie> | othermaciej: e.g. some people want profile="" out, some people want profile="" in. There's no middle ground there. |
| 09:21 | <Hixie> | othermaciej: i would be very strongly opposed to that, so, none. :-) |
| 09:21 | <othermaciej> | Hixie: that would be a new controversial issue |
| 09:22 | <Hixie> | yeah |
| 09:22 | <othermaciej> | at first reading it sounded crazy to me |
| 09:22 | <othermaciej> | but I thought, it doesn't matter if alt is mandatory if there are no conformance requirements |
| 09:22 | <Hixie> | can you imagine, if we allow <b><i></b></i>, how many people would hunt us down personally to shot us? |
| 09:22 | <othermaciej> | it doesn't matter if summary is allowed |
| 09:22 | <othermaciej> | it doesn't matter if profile is allowed |
| 09:22 | <Hixie> | shoot |
| 09:22 | <othermaciej> | I do, however, think that some people would hate it |
| 09:22 | <othermaciej> | on the basis of that |
| 09:22 | <Hixie> | it would allow <blink>! |
| 09:22 | <othermaciej> | although using the word "allow" is prejudicial |
| 09:22 | <Hixie> | we'd be forever known as the working group that allowed <blink> |
| 09:23 | <othermaciej> | the spec does not allow or disallow, it just describes what happens when you do it |
| 09:23 | <othermaciej> | (in the hypothetical world of no document conformance requirements) |
| 09:23 | <Hixie> | if ou don't disallow something, you tacitly or explicitly allow it |
| 09:23 | <Hixie> | anyway |
| 09:23 | <Hixie> | i don't see this as a path that leads to more consensus |
| 09:23 | <othermaciej> | I think it is true that document conformance requirements don't directly affect interoperability |
| 09:24 | <Hixie> | they affect validator interop |
| 09:24 | <othermaciej> | which is why they are more subjective, and thus more subject to debate |
| 09:24 | <john_fallows> | Hixie: do you want me to send feedback to the mailing list about large WebSocket frames and stream-based access instead of fully allocated buffer access? |
| 09:24 | <Hixie> | they don't affect browser interop (clearly, given 95% failure rates on the web) |
| 09:24 | <othermaciej> | they don't affect the ability of the document to work across different user agents |
| 09:24 | <Hixie> | john_fallows: i would hold off on that until we have websocket v1 implemented widely |
| 09:24 | <othermaciej> | validators only exist because there are document conformance requirements, so saying they exist for validator interop is circular |
| 09:25 | <Hixie> | john_fallows: you can though, if you want me to add it to the list of v2 features to look at later :-) |
| 09:25 | <othermaciej> | I do note that we've had almost no controversy over UA requirements, because most of the time they are essentially forced by reality |
| 09:26 | <john_fallows> | Hixie: haha - are any of the browser vendors prototyping WebSocket yet? |
| 09:26 | <othermaciej> | document conformance requirements however have no grounding in reality |
| 09:26 | <Hixie> | othermaciej: it is true that document conformance is a different issue than ua conformance |
| 09:26 | <othermaciej> | which is why people fight over them |
| 09:26 | <othermaciej> | whether or not we do anything based on this, I think it is an interesting insight |
| 09:26 | <Hixie> | john_fallows: don't think so |
| 09:27 | <Hixie> | othermaciej: i think there can be grounding in reality. it's language design, and language design can be grounded in reality. |
| 09:27 | <Hixie> | othermaciej: indeed many of the controversial points -- profile, summary, alt -- are what i perceive to be reality vs idealism issues |
| 09:28 | <othermaciej> | well, one's impression of how different requirements for those features work in practice can certainly be more or less informed by reality |
| 09:28 | <othermaciej> | but I note that for all of those, no one debates what the UA requirements should be |
| 09:28 | <othermaciej> | they only debate whether they should be allowed, forbidden, mandatory, etc for authors |
| 09:28 | <Hixie> | people have debated whether browsers should expose existing summary="" attributes or not |
| 09:29 | <othermaciej> | I don't think anyone really strongly advocates that - it's just presented as an alternative to recommending <caption> |
| 09:29 | <othermaciej> | I do not believe it stems from a sincere desire to see summary="" exposed in visual UAs |
| 09:30 | <Hixie> | granted |
| 09:32 | <othermaciej> | I personally do think validators (well, validator.nu style ones, not as much schema regurgitators) make useful QA tools |
| 09:33 | <othermaciej> | I always assumed that what they tell you about your document has to be defined by normative prose in the spec |
| 09:33 | <Hixie> | indeed |
| 09:33 | <othermaciej> | but now it is hard for me to produce a clear rationale for that |
| 09:33 | <Hixie> | it's psychological |
| 09:33 | <Hixie> | a validator can't act with authority if it doesn't have a spec to point to |
| 09:34 | <Hixie> | people ignore it and say "well that's not really the rule" |
| 09:34 | <othermaciej> | well, 'lint' and similar tools work fine without having a spec to point to |
| 09:34 | <othermaciej> | their position is not one of enforcing rules, but of helping you make your code better |
| 09:35 | <othermaciej> | or similarly gcc -W -Wall -Werror is not justified by any particular spec |
| 09:35 | <othermaciej> | but people find that more useful than gcc -ansi -pedantic, which is |
| 09:36 | <Hixie> | i think there are two reasons for that |
| 09:36 | <othermaciej> | (or at least I do) |
| 09:36 | <Hixie> | one is that the c spec sucks |
| 09:36 | <Hixie> | another is that programmers are far more likely to be technically competent and self-aware than html authors |
| 09:37 | <othermaciej> | sure, some educated html authors will want tools to help them get it right, a somewhat larger portion may be browbeaten into following rules, and a fair chunk cannot ever be forced to get it right |
| 11:46 | <Hixie> | now done up to Content Models |
| 11:51 | <Hixie> | any preference on the commas near the "can be set" text in these domintro bits? |
| 11:52 | <zcorpan_> | looks fine with the comma |
| 11:54 | <zcorpan_> | Hixie: "the body element" uses <code> in the links but not in the definition |
| 11:54 | <Hixie> | oops |
| 11:57 | <Hixie> | fixed |
| 11:58 | <Hixie> | i don't understand why firefox shows the wrong status box |
| 11:58 | <Hixie> | i just noticed it always shows the color one |
| 12:02 | <Hixie> | oh i know why |
| 12:03 | <Hixie> | the status boxes won't work for the author version |
| 12:03 | <Hixie> | hmm |
| 12:03 | <Hixie> | how to fix this |
| 12:03 | <annevk3> | about:blank can never be conforming? |
| 12:04 | <annevk3> | (it always triggers quirks) |
| 12:04 | <Hixie> | about:config fires multiple parse errors |
| 12:04 | <Hixie> | and other errors |
| 12:04 | <Hixie> | e.g. no <title> |
| 12:05 | <Hixie> | ok so maybe just two errors and one "should" violation |
| 12:05 | <zcorpan_> | what's the "should"? |
| 12:05 | <zcorpan_> | empty body? |
| 12:06 | <Hixie> | yeah |
| 12:06 | <zcorpan_> | in opera, about:blank and a non-quirky doctype and a <title> :) |
| 12:07 | <zcorpan_> | s/and/has/ |
| 12:08 | <annevk3> | for namedItem the name="" attribute case is not mentioned (and if that was intentional, for getElementsByName it is) |
| 12:12 | <Hixie> | um |
| 12:12 | <Hixie> | please to be more specific |
| 12:12 | <Hixie> | which namedItem? |
| 12:12 | <annevk3> | HTMLCollection |
| 12:14 | <Hixie> | oops |
| 12:18 | <Hixie> | fixed |
| 12:23 | <zcorpan_> | Hixie: will you generate pdfs for the author view? |
| 12:23 | <Hixie> | my plan is to not do anything for a while |
| 12:24 | <Hixie> | and then see if i can convince g or philip to make static versions |
| 12:24 | <Hixie> | and if that works, i can generate pdfs from those |
| 12:30 | <gsnedders> | So, basically, your plan is to get somebody else to do it? :) |
| 12:30 | <Hixie> | crap, g is here! |
| 12:30 | <Hixie> | run away!!! |
| 12:30 | <gsnedders> | :P |
| 12:30 | Hixie | hides |
| 12:33 | gsnedders | has a fair number of items on his to-do list due to Hixie already |
| 12:34 | Hixie | cracks the whip |
| 12:35 | <gsnedders> | That would be less scary if it weren't for the fact that one of my friends has decided to talk to me about BDSM. |
| 12:35 | Hixie | retracts the whip quickly so as to remove any confusion |
| 12:36 | <gsnedders> | See, if I hadn't also been in that conversation I would've just laughed :P |
| 12:36 | <gsnedders> | Damned friends! |
| 12:40 | gsnedders | goes back to wondering why they chose to talk to me |
| 13:26 | rubys | chuckles at the "kabuki dance" reference |
| 13:36 | <gsnedders> | I am so far behind on email this is really annoying. |
| 14:02 | <hsivonen> | http://lists.w3.org/Archives/Public/www-tag/2009Feb/0309.html |
| 14:19 | <Philip`> | Hmm, how odd, Google gave me an invalid URL in its search results |
| 14:20 | <Philip`> | <a href="http://%3c!--startfragment%20--%3eexample.com/etc" ...> |
| 14:21 | <Philip`> | (Opera says "illegal URL", Firefox says "server not found") |
| 14:55 | <partzufim> | hey all, just wanted to show you this nice new domain http://www.toolongtobecatchy.com check it out |
| 14:56 | <gsnedders> | That was _never_ spam. |
| 16:33 | <Dashiva> | The RDFa thing is more and more like some bizarro world thread. "We wanted to support [fragments] so we made am ambiguous syntax with no way of disambiguating it in fragments." |
| 17:55 | <karlcow> | Dashiva: mischaracterization ;) by using we in your sentence. |
| 17:56 | karlcow | is going to more important matters: food, poetry and sun. |
| 17:56 | <Dashiva> | What is this "sun" thing you speak of? |
| 18:00 | <Philip`> | Dashiva: It's a JS/Java bridge in Mozilla - http://code.google.com/p/doctype/wiki/ArticleHereComesTheSun |
| 20:21 | <sayrer> | wow, I have no idea what this @rel thread is about |
| 20:26 | <Philip`> | sayrer: It seems to just be about whether @rel is now a list of case-insensitive tokens or of URIs or of CURIEs, or something like that, with three different groups defining it in different ways and nobody wanting to budge from their position |
| 20:26 | <sayrer> | seriously? |
| 20:26 | <Philip`> | I think so |
| 20:27 | <sayrer> | that's what I thought they might be saying, but that would be crazy, so I thought I misunderstood |
| 20:27 | <Philip`> | (I could be wrong, since I've only skimmed over the few hundred emails about it) |
| 20:30 | <Philip`> | I guess they disagree that it's crazy |
| 20:32 | <sayrer> | yeah, if they continue to make XHTML coordination such a time sink, it seems like the easiest path for my work would be to leave XHTML5 for 2022 |
| 20:33 | <sayrer> | excellent |
| 20:35 | <Philip`> | Think of XHTML5 as X(HTML5), not as (XHTML)5 - it's actually entirely unrelated to XHTML, and is just a direct XML serialisation of HTML5, so there's no need to worry about what anyone else is doing with XHTML |
| 20:41 | <Dashiva> | Going by the HTML5/HTML 5 distinction, (XHTML)5 would be XHTML 5, wouldn't it? |
| 20:45 | <Philip`> | Dashiva: The HTML5/HTML 5 distinction exists only to shut up people who complain about the spec being biased to text/html and against XML |
| 20:45 | <Philip`> | Apart from that, nobody cares about the distinction or attempts to follow it |
| 20:46 | <sayrer> | it seems like dropping the XHTML coordination points would speed things along |
| 20:46 | <sayrer> | can't say that we get a lot of demand there, so I don't think our users are clamoring for us to do something in this area |
| 20:47 | <Dashiva> | sayrer: The RDFa-in-XHTML spec (or some related spec) defined @rel to be CURIEs, without the safe CURIE restriction. This makes some values ambiguous |
| 20:47 | <sayrer> | I wish them well :) |
| 20:47 | <Philip`> | Dashiva: Ambiguous with some other group that defined them to be URIs, do you mean? |
| 20:48 | <sayrer> | they seem to think that we MUST follow their spec |
| 20:48 | <Philip`> | (rather than being ambiguous with anything defined in HTML 5, which doesn't seem to care what you think they are because they're just strings?) |
| 20:48 | <sayrer> | I don't think they'll find that to be the case |
| 20:49 | <Dashiva> | sayrer: Not like they'll care ;) |
| 20:49 | <Philip`> | sayrer: It seems reasonable for them to think that having two specs defining incompatible behaviour for very similar formats is a problem that should be solved |
| 20:49 | <sayrer> | seems to me that criticism applies to XHTML and HTML |
| 20:49 | <sayrer> | and this is just fallout |
| 20:50 | <Philip`> | I'm not sure how the @rel issue is related to XHTML vs HTML |
| 20:50 | <Philip`> | Oh, except I suppose if @rel is a CURIE because then it doesn't make sense in HTML |
| 20:51 | <Philip`> | in which case it is an XHTML vs HTML thing |
| 20:51 | <Philip`> | and they should happily let themselves be steamrollered by HTML's requirements |
| 20:53 | <Dashiva> | I thought steamrolling was a trademark of XHTML2 |
| 20:59 | <Philip`> | As far as I'm aware, the XHTML2 group aren't the ones who flagrantly violate other people's specs and say "I don't care what you say, we have to do it this way because we've got a billion users, tough luck" |
| 21:04 | <drostie> | Are you kidding? That's basically the modus operandi of the XML developers in general. |
| 21:04 | <Dashiva> | Philip`: I suppose that's a different use of steamrolling. I limit it to forcing other people, not customizing your personal use. |
| 21:05 | <sayrer> | Philip`: yes, the issue should be addressed in time. I don't think all deliverables need to be gated on its resolution. |
| 21:10 | <Philip`> | Dashiva: I mean it in the senses like "To overwhelm or suppress ruthlessly" and "bring to a specified state by overwhelming force or pressure", progressing strongly towards one's own goals by overriding any objections that get in the way |
| 21:10 | <Hixie> | Philip: it also exists to give me something to say when someone asks me the ridiculous question of whether there should be a space between the L and the 5 |
| 21:14 | <drostie> | Hixie: why not just say "there should be TWO spaces between the L and the 5" ...? |
| 21:14 | <drostie> | ridiculous questions deserve ridiculous answers ^_^ |
| 21:43 | <Dashiva> | drostie forgot that multiple whitespace leads to discussions about normalizing whitespace :) |
| 21:45 | <Philip`> | Can I write HTML5? |
| 21:48 | <drostie> | Philip`: I think it should be a non-breaking space, making it HTML�A0;5 . ^_^ |
| 22:57 | <Philip`> | krijnh: Why does http://krijnhoetmer.nl/irc-logs/whatwg/20090228 say "2009-02-22" at the top? |
| 22:58 | <Philip`> | and similarly why does http://krijnhoetmer.nl/irc-logs/whatwg/20090301 say "2009-03-30"? |
| 22:59 | <jcranmer> | Philip`: time travel? |
| 23:05 | gsnedders | checks to see what he said next month |
| 23:19 | <rubys1> | sayrer: the encouragement is not a requirement, but does specifically mention RDFa... |
| 23:20 | <sayrer> | rubys, it looks like the encouragement is for an extensibility mechanism |
| 23:20 | <sayrer> | rubys1^ |
| 23:20 | <sayrer> | that RDFa might use |
| 23:22 | <sayrer> | "such as" is the key here, if you ask me |
| 23:42 | <Dashiva> | Marking up the KT extinction event with <time>... |