| 01:38 | <Lachy> | Hixie, the spec defines "semi-transparent" content models, but there don't appear to be any elements that use that as their content model. Is that an old content model that is no longer used, or one you intend to use for some elements later? |
| 01:42 | <Lachy> | I suppose it's something that could be used for the object element, except that its description just says "Zero or more param elements, then, transparent." |
| 01:52 | <Dashiva> | I think that's what semi-transparent was used for, yeah |
| 01:58 | <Dashiva> | Hmm no... video and audio were semi-transparent until the change where strictly inline content was obsoleted. |
| 02:05 | <Dashiva> | http://www.techcrunch.com/2009/01/31/nielsen-deletes-reply-to-all-button/ |
| 02:16 | <Lachy> | wtf? the Reply All button is essential, disabling it is a bad idea |
| 02:35 | <Hixie> | Lachy: send mail or file a bug and i'll fix it up when doing editorial fixes |
| 02:35 | <Hixie> | oh you did |
| 02:35 | <Hixie> | thanks! |
| 04:02 | jwalden | likes his Reply to All because usually that's what he wants, and he remembers more to remove addresses than to add all of them |
| 04:02 | <jwalden> | I deled the Reply button from my toolbar and left only the all counterpart to help |
| 06:46 | <Hixie> | i am amused at the people talking about how public-html is dysfunction in a thread that is about 5 steps removed from discussion of spec material |
| 07:27 | <Hixie> | compare the rule for fieldset in these two files: |
| 07:27 | <Hixie> | http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css |
| 07:28 | <Hixie> | http://trac.webkit.org/export/40471/trunk/WebCore/css/html4.css |
| 07:28 | <Hixie> | i wonder why the numbers are rotated around |
| 07:28 | <Hixie> | that makes no sense to me |
| 07:29 | <Hixie> | i wonder who copied who and who changed |
| 07:31 | <Hixie> | http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/style&command=DIFF_FRAMESET&file=forms.css&rev2=3.76&rev1=3.75 |
| 07:32 | <Hixie> | http://trac.webkit.org/changeset/10579 |
| 07:32 | <Hixie> | how amusing |
| 07:32 | <Hixie> | they both started the same and forked in different ways |
| 07:33 | <Hixie> | looks like hyatt screwed that one up |
| 07:42 | <jwalden> | you're surprised? I mean, come on: http://images0.cafepress.com/product_zoom/1417340v1_400x400_Back.jpg ;-) |
| 09:06 | jgraham | wonders if using minidom with Lachy's script makes it horribly slow |
| 09:06 | <jgraham> | (but I'm too lazy to try it out) |
| 09:07 | Philip` | assumes that merely using html5lib makes it horribly slow |
| 09:07 | <jgraham> | Well yes, there is that :) |
| 09:08 | <Hixie> | i wonder why eric meyer wants value="" on <input type=image> |
| 09:08 | <Hixie> | so much that he switched to xhtml to use it |
| 09:08 | <jgraham> | (FWIW the python 3 version seems to be slightly faster although that was a totally non scientific test that involved me remembering the speed parsing the html5 spec) |
| 09:09 | <Philip`> | (Does it pass tests too?) |
| 09:11 | <jgraham> | (Yes, it seems to) |
| 09:12 | <Philip`> | (Sounds good!) |
| 09:12 | <jgraham> | (But that may not mean much; I couldn't check the output when running against the html5 spec because python3 decides that sys.stdout redirected to a file takes strings with default character encoding mac-roman (on a mac) and I couldn't work out how to change that) |
| 09:13 | <jgraham> | (so it just bails with an encoding error) |
| 09:13 | <Hixie> | what's all the whispering over there in the corner |
| 09:13 | <Hixie> | are you guys plotting some evil scheme |
| 09:14 | <hsivonen> | if they are, that's not krijn's secrecy syntax |
| 09:15 | jgraham | is just wwhispering about python 3 html5lib in case someone accidentially overhears and takes it seriously |
| 09:19 | <Lachy> | jgraham, yeah, it probably is slow because of minidom. But that was the only one with an API I was relatively familiar with and actually had a chance of getting something working |
| 09:22 | <Lachy> | Speed wasn't really a concern for me. It's not something that needs to run every day. Only when Hixie makes an update to the element summaries in the spec. But if someone would like to make it faster for me using a better API, that would be appreciated. |
| 09:24 | <jgraham> | Lachy: FWIW if you are planning to ever write another [HT|X]ML manipulating script in python, it is weel worth your while to learn the ElementTree/lxml api |
| 09:24 | <jgraham> | *well |
| 09:31 | <Lachy> | jgraham, I did try once, but it had some really weird design that made it unintuitive to work with |
| 09:32 | <Lachy> | like the element tail, which is text node after an element that, instead of just being attached to the parent, is attached to the previous element node |
| 09:35 | <jgraham> | Lachy: Yeah the .text .tail thing is a bit weird. Although it makes much more sense when you realise that ElementTree doesn't think of text as a type of Node any more than it thinks of attributes as a type of Node. It thinks of text as a property of Elements |
| 09:38 | <Lachy> | jgraham, .text makes a little more sense than .tail though, because at least .text is contained within the element itself. Whereas .tail means that you can't just remove an element from the tree, without first taking the tail and appending it to the previous sibling's .tail or the parent's .text |
| 09:41 | <jgraham> | Lachy: What else can you do apart from .tail if you want to view text as a property? The concept of text nodes is also pretty problematic because you typically have to check whether each node is a text node or a element node when you iterate through the tree, and you can have non-normalized text nodes and so on |
| 09:42 | <Lachy> | jgraham, that's just a design flaw of the DOM which only had .childNodes instead of .childElements or maybe .childNodes(nodeType) |
| 09:43 | <Lachy> | ElementTraversal partially fixes those issues though |
| 09:55 | <Hixie> | a text-centric DOM would be interesting (basically, just a list of all the Text nodes, with a property on each one listing the elements that that node was in, and its attributes) |
| 10:08 | Hixie | ponders default styles for the new elements |
| 10:09 | <annevk> | can we make <button action=http://www.google.com/>TEST</button>; work without requiring a form ancestor? |
| 10:10 | <Hixie> | i don't know of anything blocking us from doing that other than spec and implementation complexity |
| 10:12 | <Lachy> | annevk, what's the use case for doing that? |
| 10:12 | <wilhelm> | I'd rather have <a href='./delete/1337/' method='post'>delete</a>. |
| 10:13 | <Hixie> | wilhelm: that has a much worse back-compat story |
| 10:13 | <Hixie> | wilhelm: one that actually encourages people to do the wrong thing |
| 10:13 | <jgraham> | wilhelm: I'll let you duel that one out with the HTTP guys |
| 10:14 | jgraham | doesn't believe that users make any distinction between "safe" links and "unsafe" buttons |
| 10:14 | <Lachy> | oh, so the use case is: <button action="..." name=delete value=whatever> or any other action for which POST is more suitable than GET |
| 10:15 | <wilhelm> | True. But adding all that extra markup and having to restyle the button just to get a safe link is a pain:P |
| 10:16 | <Hixie> | annevk: the main difficulty spec-wise would be doing it in a way that doesn't include all the other elements that don't have a form in the same form |
| 10:16 | <Lachy> | jgraham, it's not really users that need to make the distinction. It's more the tools that automatically prefetch links and bots that should avoid non-idempotent actions |
| 10:16 | <Hixie> | annevk: but it could be done |
| 10:18 | <Lachy> | wilhelm, we just need the CSS3 'appearance' property to be implemented so that buttons can be more easily styled to look like links |
| 10:18 | <jgraham> | Lachy: in principle <a method=foo> allows them to make that distiction (obviously it is not backwards compatible. Lots of people seem to argue that *users* make that distinction |
| 10:18 | <Hixie> | wilhelm: don't make delete buttons look like links. links are for navigation, it's bad ui to make them do things. |
| 10:18 | <Lachy> | jgraham, yeah, a lot of people have flawed arguments. |
| 10:19 | <annevk> | it seems better to keep <a> GET-only |
| 10:19 | <annevk> | at least as far as href="" is concerned |
| 10:19 | <Lachy> | Hixie, whether it's a good idea or not, there are designers out there that insist on it, despite the stupidity |
| 10:21 | <annevk> | Hixie, any chance you could work on cross-origin media element loading before doing the rest of rendering? |
| 10:21 | jgraham | thinks it is not obviously stupid to make link-like things perform actions |
| 10:22 | <Lachy> | I suspect that the only distinction that users make between buttons and links is that buttons send information, usually what they type into a form, whereas links just retrieve data. |
| 10:22 | <Hixie> | Lachy: doesn't mean we should make it easier. quite the contrary. |
| 10:22 | <Hixie> | annevk: what is there to do? |
| 10:22 | <annevk> | Hixie, I filed a bug; currently file size is exposed due to progress events |
| 10:22 | zcorpan_ | notes that Hixie's table example works with the Smart Headers algorithm |
| 10:23 | <jgraham> | Or, more specifically, I think that if easy-to-use UIs use links to perform actions then they are, by example, good UI |
| 10:23 | <Hixie> | annevk: i'm not planning on doing anything with progress events until progress events is done |
| 10:23 | <Lachy> | zcorpan_, which table example? |
| 10:24 | <jgraham> | zcorpan_: Smart Headers doesn't distinguish between roww and colum headers which was one of aaron's requirements stemming from the way one of the accessibility apis works |
| 10:24 | <Hixie> | annevk: specifically, i'm waiting for chaals to respond to http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0047.html |
| 10:24 | <annevk> | Hixie, people are shipping/implementing progress events though |
| 10:24 | <annevk> | hmm ok |
| 10:24 | <zcorpan_> | Lachy: http://www.w3.org/mid/Pine.LNX.4.62.0901312117510.14270⊙hdc |
| 10:25 | <zcorpan_> | jgraham: ok |
| 10:26 | <Hixie> | annevk: not my fault people are shipping specs that aren't even in LC yet :-) |
| 10:26 | <Lachy> | zcorpan_, oh, yeah. That's the one where Hixie was pointing out that "the algorithm is likely going to support far fewer table types without attributes [than smart headers]" |
| 10:27 | <Hixie> | annevk: progress events will hopefully change quite a bit, so those impls will have to change anyway |
| 10:28 | <Hixie> | annevk: for example, progress events seems to imply that 'load' should include the information you say is problematic, but 'load' is fired for <img>, e.g. |
| 10:31 | <zcorpan_> | Lachy: i thought he meant "[than the previous algorithm in the spec]" |
| 10:31 | <Hixie> | i meant hte latter, but the former is true also |
| 10:33 | <jgraham> | I wonder how useful it is that the accessibility things distinguish between row and column headers. Does aria account for this? |
| 10:34 | <jgraham> | Or is HTML expected to apply the same magic to aria attributes as it does to @headers? |
| 10:34 | <Hixie> | i don't think that the algorithm not handling this table is a big deal |
| 10:34 | <Hixie> | real tables don't look like this usually |
| 10:34 | <Hixie> | and when they do, going both ways is almost always wrong |
| 10:34 | <Hixie> | iirc |
| 10:36 | <annevk> | Hixie, ta |
| 10:36 | <Hixie> | np |
| 10:42 | <Lachy> | Hixie, http://www.whatwg.org/specs/web-apps/current-work/revision.dat didn't get updated with the last 2 checkins. Current revision is 2735, but that still says 2733 |
| 10:43 | <Hixie> | yeah, that happens when twitter fails |
| 10:43 | <Hixie> | i guess i should ignore twitter errors |
| 10:43 | Hixie | moves things around |
| 10:43 | <Hixie> | should work next time |
| 10:46 | <Lachy> | Hixie, 10.2 Hidden Elements: this Selector is missing a comma after audio:not(...) [hidden], area, audio:not([controls]) base, basefont, |
| 10:46 | <hsivonen> | wow. twitter as a system integration platform |
| 10:46 | <Hixie> | thx |
| 10:48 | <Hixie> | so uh |
| 10:48 | <Hixie> | can anyone think of a way of doing http://damowmow.com/temp/sectioning.css that won't get me shot by the browser vendors |
| 10:48 | <Lachy> | Hixie, rather than givign @namespace for all CSS, wouldn't it be easier to just say that the namespace applies to all CSS in this section? |
| 10:49 | <Hixie> | Lachy: it would be easier, yes, but being explicit seems safer |
| 10:50 | <Lachy> | ok |
| 10:50 | <annevk> | Hixie, except that merging all the CSS snippets would not result in a valid style sheet currently |
| 10:51 | <annevk> | Hixie, though I suppose that cannot be done anyway given that quirks is also listed throughout |
| 10:51 | <Hixie> | if anyone tries to merge them, they're going to have far bigger problems than that |
| 10:52 | <hsivonen> | Hixie: h1:outline-depth(n) |
| 10:52 | <Hixie> | a way that doesn't involve waiting longer than 2022 would be ideal |
| 10:52 | <annevk> | yeah, the only way forward there is some optimized selector I think |
| 10:53 | <annevk> | can't we get the CSS WG to approve of a vocabulary specific selector? |
| 10:54 | <Hixie> | q.v. my earlier remark regarding 2022 as a deadline |
| 10:54 | <annevk> | btw, why would you ever want the h1 to be smaller than the rest of the text? |
| 10:55 | <Lachy> | annevk, we'd hav a much greater chance of getting the CSSWG to accept any selectors if we can find a way to help push CSS3 Selectors to REC, ASAP |
| 10:55 | <Hixie> | (selectors has been "done" since 2001, and has had interoperable implementations for at least a year, and it is still not in PR, so i'm not holding my breath) |
| 10:55 | <Hixie> | annevk: the sizes are just h2-h6 |
| 10:55 | <hsivonen> | annevk: it's not vocabulary-specific if it is abstacted like class selectors such that a vocabulary gets to define how it hooks to the selector |
| 10:56 | <Lachy> | Hixie, there are still some minor interop issues with ::selection. But most of the rest is largely interoperable |
| 10:56 | <jgraham> | Of course if the CSSWG are dysfunctional to the extent that they are blocking us, we should fix the CSSWG not try to route around them |
| 10:56 | hsivonen | has a hard time remembering when to use : and when :: |
| 10:57 | <Hixie> | hsivonen: : = class-like things, :: = element-like things |
| 10:57 | <annevk> | hsivonen, that would work too |
| 10:57 | <Lachy> | hsivonen, how is that hard? I find the differece between pseudo-elements and -classes easy |
| 10:57 | <hsivonen> | is WebApps considered functional? |
| 10:57 | <Hixie> | hsivonen: so : = actual elements, :: = things not actually in the DOM |
| 10:58 | <annevk> | hsivonen, I think it is |
| 10:58 | <hsivonen> | Lachy: I can understand the distiction--I can't remember which takes two colons |
| 10:58 | <hsivonen> | annevk: cool |
| 10:59 | <Hixie> | so uh, why can't my web server resolve twitter.com in dns |
| 10:59 | <hsivonen> | so I should remember that :: is less real than : |
| 10:59 | <annevk> | or : is closer to . than :: |
| 11:01 | <zcorpan_> | Lachy: i'd suggest renaming the section to "Getting started with HTML" since you can "get started with HTML5" if you already know html4 but the section is targetted at beginners |
| 11:02 | <Lachy> | zcorpan_, send mail to public-html |
| 11:03 | <Lachy> | zcorpan_, I'm trying to stimulate some actual productive discussion about it on the list, but so far it has resulted in an off-list mail and people pinging me on IRC. |
| 11:04 | <Lachy> | also, I'm not working on the guide today, so the mail will make sure I remember |
| 11:13 | Hixie | standardises <blink> |
| 11:28 | <Lachy> | Hixie, sometimes you include a blank line after @namespace and other times you don't. Please be consistent. |
| 11:29 | <Hixie> | i include it when there is more than one block of text in the css block |
| 11:30 | <Lachy> | ok |
| 11:39 | <Hixie> | the rendering section's table of contents is oddly bell-shaped |
| 11:46 | <annevk> | "The fgColor attribute on the Document object must reflect the text attribute on the body element." does not say what should happen when there is no body element |
| 11:46 | <annevk> | the same might be true for <body onload> when there is no Window object, come to think of it |
| 11:48 | <Hixie> | the obsolete features section is scheduled for april/may |
| 11:48 | <Hixie> | the body.onload thing is a good point; file a bug? |
| 11:48 | <Hixie> | i'm going to bed now |
| 11:48 | <Hixie> | nn |
| 11:48 | <Hixie> | and thanks |
| 11:49 | <hsivonen> | Hixie: what's the browser implementor interest status of <datagrid>? |
| 11:49 | <annevk> | sure, nn |
| 11:49 | <hsivonen> | oh, nn |
| 11:51 | <annevk> | afaict there was only interest from a Chrome guy |
| 11:52 | <annevk> | but they're not working on their rendering engine that much (other than porting) so... |
| 11:52 | <hsivonen> | annevk: Chrome interest would be understandable considering that the widget seems very applicable to Gmail |
| 12:02 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html first block lacks a line break after @namespace |
| 12:02 | <annevk> | same for the last |
| 12:02 | <annevk> | and the penultimate |
| 12:04 | <annevk> | or is that some rendering bug in Opera? hmm |
| 12:04 | <Lachy> | annevk, I pointed out the same issue. <Hixie> i include it when there is more than one block of text in the css block |
| 12:05 | <annevk> | Lachy, no, that's a different issue |
| 12:05 | <annevk> | or a non-issue, as it happens :) |
| 12:08 | jgraham | would prefer a consistent line break after the @namespace because it it non-trivial to deduce what the rule is |
| 12:09 | <Lachy> | annevk, how is it a different issue? |
| 12:09 | <annevk> | Lachy, what I encounter is a rendering issue in Opera |
| 12:09 | <annevk> | Lachy, what you encounter is a source code thingy |
| 12:10 | <Lachy> | oh, Opera bug |
| 12:11 | <Lachy> | annevk, do you want to file a bug and CC moose and I about it? |
| 12:13 | <annevk> | sure |
| 12:15 | <annevk> | done |
| 12:17 | <annevk> | hsivonen, ah, requiring NFC from content is another nice trick :) |
| 12:17 | <annevk> | hsivonen, I quite strongly agree that keeping identifier comparison as simple as possible is a good thing |
| 12:18 | <hsivonen> | annevk: CharmodNorm FTW! |
| 12:23 | <hsivonen> | http://diveintomark.org/archives/2004/07/06/nfc |
| 12:24 | <annevk> | I remember it took me quite a while before I understood that post |
| 12:24 | <annevk> | It was also the first time I heard of the problem |
| 14:05 | <takkaria> | Hixie: 10.3.5, the rule for h2 gives a smaller font size than that for h1 |
| 14:07 | <gsnedders> | Who here uses Anolis? |
| 14:11 | <gsnedders> | Hixie: HTML 5 itself assumes 10.4.1 does not apply |
| 14:13 | <annevk> | I want to use Anolis once the serializer is more friendly and W3C specgen like |
| 14:23 | <Lachy> | gsnedders, I do |
| 14:23 | <Lachy> | annevk, anolis has the --w3c-compat options |
| 14:24 | <Lachy> | AFAIK, it's just missing the biblio stuff |
| 14:24 | gsnedders | guesses annevk means things like biblio and indexing |
| 14:24 | <gsnedders> | Lachy: And other things |
| 14:25 | <Lachy> | yeah, lack of biblio is annoying. Though I'm using it successfully for the HTML5 Reference, and it works really well |
| 14:30 | <rubys1> | Lachy: ping? |
| 14:32 | <jgraham> | annevk: I have a WIP of the updated online interface for anolis at home |
| 14:32 | <jgraham> | But I don't quite know how to sanely deal with the fact that there are two forms and dozens of controls that should apply to both |
| 14:33 | <Lachy> | rubys, pong |
| 14:33 | <jgraham> | WWithout just copying the controls or requiring js |
| 14:33 | <rubys> | It generally is considered rather rude and a significant violation of Netiquitte to publish a private reply in a more public forum. |
| 14:33 | <rubys> | Had you asked, I would have given permission. |
| 14:33 | <Lachy> | rubys, I figured since it was a process issue, you wouldn't mind |
| 14:34 | <Lachy> | and also because the discussion was related to replying publicly, to which you said +1 |
| 14:34 | <rubys> | regarding "number of people who support an idea": if a person makes a solid argument and the editor agrees and nobody disagrees, then you are right: no additional support needs to be expressed. |
| 14:34 | <rubys> | If a person makes a sold argument and the editor disagrees is where it gets interesting. One special case that I want to dispose of quickly, however. That is when that one person either can't find anybody to support the argument, or can only find people in their own organization to do so. |
| 14:36 | <Lachy> | if a person can't find any support, except from their own organisation, then it's unlikely that they have made a solid argument |
| 14:37 | <rubys> | There is no absolute scale upon which arguments can be measured. |
| 14:38 | <rubys> | HTML5 is largely based not on what is "right", but on what "works". Multiple things could possibly work, and reasonable people can disagree as to which is best. |
| 14:39 | <rubys> | On such matters, I tend to defer to the editor when the matter is one of personal taste. |
| 14:40 | <Lachy> | agreed |
| 14:40 | <rubys> | the thing we need to collectively find a way to address is one where people feel disenfranchised because they are not given an opportunity to be heard. |
| 14:42 | <Lachy> | I'm not sure how to address that. People just need to learn that some times their ideas are rejected, no matter how passionately they feel about them. Those who feel disenfranchised are not alone in that respect. It's just that those of us who don't feel disenfranchsed know how to accept and move on |
| 14:42 | <rubys> | Apparently that's what David Dailey feels. And an answer that can be interpreted as you intend to be the sole judge of merit base on your own standards of technical worth reinforces that concern. |
| 14:43 | <jgraham> | Does anyone know off hand where unicode defines the mapping between char+combining char into single NFC char (for some appropriate definition of char) |
| 14:43 | <Lachy> | well, I remain concerned about the ability of concensus based approaches to do any better, and so I'm hesitant to adopt that method |
| 14:43 | <Lachy> | jgraham, http://www.unicode.org/reports/tr15/tr15-25.html |
| 14:45 | <gsnedders> | jgraham: It's all in the UCD |
| 14:45 | <rubys> | Ian didn't pick a new DOCTYPE based on consensus. In fact, he explicitly ignored one of your concerns. But I am very happy with the process that that decision was made. |
| 14:46 | <jgraham> | gsnedders: So there is no unique table that says codepoint x + codepoint y maps to codepoint z under NFC? |
| 14:46 | <gsnedders> | jgraham: AFAIK no |
| 14:46 | <rubys> | Mark Davis would know, and tends to be very responsive. |
| 14:47 | <Lachy> | rubys, I'm aware that Hixie ignored one of my concerns. But I trust Hixie to have evaulated and weighed up all concerns, and I accept his decision. |
| 14:47 | <rubys> | You've built that trust up over time. Not everybody yet has that perspective. |
| 14:48 | <annevk> | gsnedders, I mean pretty source code, mostly :) |
| 14:48 | <annevk> | gsnedders, though a good solution to biblio would be neat, one based on a wiki or some such |
| 14:48 | <gsnedders> | annevk: That's not an Anolis-level issue :) |
| 14:48 | <rubys> | Anyway, my point is that it is not a binary point about consensus vs dictator. |
| 14:48 | <annevk> | gsnedders, it affects me though :) |
| 14:48 | <Lachy> | well, with this issue, given that my concern was only minor, making such fuss about this one would detract from more important issues |
| 14:48 | <gsnedders> | annevk: Fussy boy :) |
| 14:49 | <rubys> | Lachy, I'm sorry, which issue are you talking about? DOCTYPE or David's? If the former, I agree. If the latter, I disagree. |
| 14:50 | <Lachy> | DOCTYPE |
| 14:50 | <jgraham> | It seems that not everyone thinks that the term "benevolant dictator' has positive connotations |
| 14:50 | <rubys> | jgraham: bingo |
| 14:51 | <hsivonen> | we really should avoid 'dictator' and talk about 'strong editor model' or something |
| 14:51 | <rubys> | I am to get people who raise objections to realize that they are either alone or truly are describing a matter of taste whenever possible. |
| 14:51 | <jgraham> | rubys: I guess I shouldn't make it sound like news since it has been known about for some time. |
| 14:51 | <jgraham> | Like forever |
| 14:51 | <Lachy> | hsivonen, "benevolent arbiter" |
| 14:52 | <rubys> | strike benevolent |
| 14:52 | <Lachy> | why? It only has good connotations |
| 14:52 | <rubys> | only if it is accurate |
| 14:53 | <Lachy> | ? |
| 14:53 | <rubys> | Ian is as opinionated and biased as the rest of us. In some ways more so. He also is immensely talented and reasonable. |
| 14:53 | <hsivonen> | Lachy: the whatwg model isn't counting on Hixie being benevolent. it counts on keeping Hixie in check by the threat of withdrawing implementor participation |
| 14:55 | <jgraham> | (This is not, in practice so different from the Python model which allows for the possibility of forking if Guido turns bad) |
| 14:57 | <Lachy> | As I pointed out yesterday, some people involved with HTML4all has sort of forked the spec, which should turn out to be a good thing in the long run |
| 14:57 | <annevk> | hsivonen, http://en.wikipedia.org/wiki/Oligopoly ? |
| 14:58 | annevk | shrugs |
| 14:58 | <Lachy> | since we can review their work on the forked spec and incorporate any good changes |
| 14:59 | <rubys> | I also claim that the WHATWG model also provides ample excuse for one significant vendor to not participate. That concerns me greatly. Not that they would participate anyway, but that they have a convenient excuse provided for them. |
| 14:59 | <Lachy> | rubys, I think the only reason Microsoft doesn't participate is the lack of patent policy |
| 14:59 | <hsivonen> | annevk: I'm not implying that. I mean that Hixie is not interested in writing fiction. |
| 15:00 | <jgraham> | Lachy: That is clearly untrue |
| 15:00 | <Lachy> | jgraham, how so? |
| 15:00 | <Lachy> | I recall Chris Wilson saying something to that effect before |
| 15:00 | <hsivonen> | rubys: having a patent policy and having an editor with latitude kept in check by the possibility of implementors getting angry are not mutually exclusive |
| 15:00 | <jgraham> | Lachy: Microsoft have effective participated in neither HTMLWG or WHATWG and what participation has occured has been split roughly equally amongst both |
| 15:01 | <rubys> | Lachy: s/only reason/one reason/ |
| 15:01 | <Lachy> | rubys, other reasons? |
| 15:01 | <annevk> | jgraham, they participated in the WHATWG? |
| 15:02 | <rubys> | Lachy: has MSFT participated in any great extent in the W3C working group? If not, it must be for reasons other than patent policy. |
| 15:02 | <jgraham> | annevk: 5 messages |
| 15:02 | <annevk> | hsivonen, whether or not you imply that, it seems pretty accurate; not sure whether it's good or bad though, the Web is quite different from market economy |
| 15:02 | <annevk> | jgraham, oh, didn't know |
| 15:02 | <Lachy> | I only counted 4. Maybe I'm missing one |
| 15:03 | <jgraham> | Lachy: presumably they don't see the business value in participating |
| 15:03 | <rubys> | hsivonen: agreed, but I don't believe I said otherwise. Having an editor latitude kept in check is a good thing, and implementors getting angry is one possible way to partially address that. |
| 15:04 | rubys | bows in jgraham's general direction |
| 15:06 | <Lachy> | rubys, although the implementer threat works for the whatwg, there are people who tend not to care much for implementers and would prefer authors have more influence, even at the expence of implementers |
| 15:06 | <Lachy> | *expense |
| 15:06 | <rubys> | It is not a zero sum game. |
| 15:07 | <rubys> | Author's clearly ran amok for a number of years at the W3C. A redressing of the imbalance was appropriate. Now we need to find a happy middle. |
| 15:10 | <jgraham> | It is worth noting that it is a constrained optimisation problem. If you try to make implementors do things they don't want to do --- because they are too complex or because users wouldn't like them, for example --- they will stop playing ball. If you ask authors to jump through unreasonable hoops they will use a differnt format instead. |
| 15:11 | <hsivonen> | too bad authors too often miss that it's not zero-sum. particularly, without browser vendor participation, there's no platform to deploy new content features on |
| 15:13 | <rubys> | too bad implementers often miss that it's not zero-sum. Particularly, without user participation, there's platforms designed to deploy new content features on simply go unused. |
| 15:15 | <jgraham> | rubys: I had difficulty understanding your second sentence |
| 15:15 | <rubys> | yea, I typed it so fast, it hardly was intelligible. |
| 15:16 | <rubys> | hsivonen's statement is equally true from the other perspective. I've seen many platforms designed with a "if you build it, they will come" perspective. |
| 15:16 | <hsivonen> | rubys: has that been a problem in practice? what platforms have gone unused due to lack of user participation? |
| 15:16 | <Philip`> | If implementors add a feature that 1% of authors want to use, it's a pretty successful feature; if authors request a feature that 1% of implementors want to implement, it's useless to everybody |
| 15:16 | <rubys> | To avoid any sacred cows here, I'll pick something safe: Hailstorm. |
| 15:17 | <hsivonen> | rubys: I meant features of the interoperable Web runtime platform |
| 15:17 | <Lachy> | rubys, implementers do realise that it's not a zero-sum game, and in many cases, we explicitly do look at what authors use and don't use |
| 15:17 | <Lachy> | and what they don't, we cut from the spec |
| 15:17 | <hsivonen> | rubys: it seems to me that features are generally unused because they haven't been implemented in all significant runtimes |
| 15:17 | <hsivonen> | rubys: rather than because users rejected them |
| 15:17 | <rubys> | Some people apply that loosely, others more tightly. Take for example this perspective: http://blog.mozilla.com/rob-sayre/2009/02/01/conventional-wisdom/ |
| 15:20 | <Lachy> | The spec itself isn't a great place for innovation, although it does happen occasionally. Most of the innovation comes from browser vendors who then present their innovations to be specced |
| 15:21 | <Lachy> | this is most clearly demonstrated by canavs, video, <input placeholder="">, .innerHTML, etc. |
| 15:21 | <Philip`> | hsivonen: There are features that have been interoperably implemented in the browsers used by 95% of the market, and many have been successful but many others appear to be effectively unused on the public web |
| 15:21 | <rubys> | Lachy: I agree with the fourth example in that lst. |
| 15:21 | <Philip`> | hsivonen: e.g. IE's <table datasrc> stuff |
| 15:22 | <hsivonen> | Philip`: has datasrc been implemented in anywhere but IE? |
| 15:23 | <Philip`> | hsivonen: No, but it's been available in the browsers used by 95% of the market, and lots of people were happy to write pages solely for that subset of the market |
| 15:23 | <Lachy> | rubys, what about the other 3? |
| 15:23 | <annevk> | Lachy, <canvas> and <video> have changed quite a bit by WHATWG input |
| 15:23 | <jgraham> | rubys: Of course leaving the platform much more static (which seems to be what rsayre wants) has its share of problems. Notably that people start to view you as "damage" that must be worked around by e.g. using Flash or Silverlight |
| 15:23 | <annevk> | placeholder="" only has a single impl |
| 15:24 | <rubys> | jgraham: be careful when you read motivation into people |
| 15:25 | <rubys> | Something I have said many times: I'd love to see something smaller get to CR status in 2010; and leave the rest to defend for itself. I don't see anything in rsayre's message that differs from that vision. |
| 15:25 | <jgraham> | rubys: I don't think I was reading motivation (motivation would be "I want HTML to be static so flash usage increases" or somesuch). I agree it is possible that I misinterpreted his position. |
| 15:25 | <Lachy> | annevk, that doesn't change the fact that the initial innovation occurred outside of the spec. It's just that the spec is good at refining, not innovating |
| 15:26 | <rubys> | "seems to be what rsayre wants". It could be that he simply doesn |
| 15:26 | <rubys> | 't want to wait for a CR in 2012. |
| 15:27 | <jgraham> | It could be. I'm still not sure why people focus so much on dates for spec transitions when the only real quantity is "when is this implemented in the UAs I care about so I can use it" |
| 15:28 | <Philip`> | rubys: Point 7 on http://blog.mozilla.com/rob-sayre/2009/01/19/where-memes-go-to-die/ sounds like he's concerned with issues other than the timetable for the spec |
| 15:28 | <rubys> | Anyway, I've said what I wanted to say, namely that violating the expectations of private email is bad form, and setting up a dictatorial process, allegedly benevolent or otherwise, is counter to the goal of soliciting any and all input. |
| 15:29 | <rubys> | Philip`: agreed, but that doesn't mean that he's for a more static platform. |
| 15:29 | <BenMillard> | Hixie, I've replied to that table example on Public-HTML. |
| 15:30 | <rubys> | For all I know, it could mean that; I've only met him a few times (he worked on Atom prior to joining Moz); I just wouldn't jump to that conclusion. |
| 15:31 | <karlcow> | jgraham: cf dates: some of the things are not visibly implemented but some groups do care about them. For example a blockquote. The meaning of it has no concrete implementation in browsers (except the block nature) but the semantics matter outside of the browser world. |
| 15:33 | <annevk> | karlcow, <time> doesn't matter for browsers either |
| 15:33 | <annevk> | karlcow, and <section> etc. don't matter much to us either |
| 15:34 | <karlcow> | annevk: indeed, yes same example |
| 15:36 | <jgraham> | annevk: Actually <time> and <section> improve a lot with some implementation love |
| 15:53 | <annevk> | so it seems the i18n guys are arguing for doing Unicode Normalization while comparing strings |
| 15:53 | <annevk> | ouch |
| 15:53 | <gsnedders> | annevk: What form of Normalization? |
| 15:54 | <annevk> | a form, though NFC has been suggested |
| 15:54 | <zcorpan> | Hixie: i think <layer> doesn't need display:block |
| 15:54 | <gsnedders> | NFK[CD] and NF[CD] would have different results |
| 15:54 | annevk | thinks the rendering section should be normative for a very specific class of UAs |
| 15:54 | <zcorpan> | Hixie: nor <multicol> |
| 15:55 | <rubys> | annevk: the Mac is notorious for using NFD whereas NFC is commonplace everywhere else. |
| 15:56 | <rubys> | annevk: do you have access to a mac with Apache? |
| 15:56 | <annevk> | yeah, they mentioned that |
| 15:56 | <annevk> | not right now |
| 15:56 | <annevk> | actually, lets make that "no" |
| 15:56 | gsnedders | does |
| 15:57 | <annevk> | zcorpan, I wonder how Hixie arrived at <layer> |
| 15:57 | <rubys> | Create a file with an accented character in your sites directory |
| 15:57 | <gsnedders> | Yeah, it'll be NFD |
| 15:57 | <annevk> | aren't IRIs NFC? |
| 15:58 | <gsnedders> | annevk: Not always |
| 15:58 | <gsnedders> | rubys: What do you want to see? |
| 15:58 | <rubys> | if somebody copy/pastes a URI with an accented character into a browser on windows or ubuntu, they won't be able to access your file on the mac. |
| 15:58 | <rubys> | I have access to a mac, I just wanted to demonstrate the problem. |
| 15:59 | <annevk> | gsnedders, it seems that if it's not NFC it's not a IRI |
| 15:59 | <gsnedders> | Hmm |
| 15:59 | <annevk> | oh no |
| 15:59 | <annevk> | you're right |
| 15:59 | <gsnedders> | If I request using pct-encoding of the NFC form it still works |
| 15:59 | <rubys> | gsnedders: that's not been my experience |
| 16:02 | karlcow | has apache running on my mac |
| 16:05 | <rubys> | karlcow: cd ~/Sites; mkdir foo; cd foo; touch Señor |
| 16:05 | <karlcow> | http://la-grange.net/2009/02/02/love-é-愛.txt |
| 16:05 | <karlcow> | and it is working in local |
| 16:06 | <rubys> | it appears to be working, but view source |
| 16:06 | <rubys> | I get href="Sen%cc%83or" |
| 16:07 | <karlcow> | working in Opera 10 alpha at least |
| 16:07 | <karlcow> | testing with others |
| 16:08 | <rubys> | repeating on Ubuntu, I get href="Se%c3%b1or" |
| 16:09 | <rubys> | karlcow: are you doing all of your testing on mac? |
| 16:09 | <karlcow> | the difference between Opera and Safari. Safari displays at the top of the window the right characters and opera displays http://lagrange.test.site/2009/02/02/love-e%CC%81-%E6%84%9B.txt |
| 16:09 | <karlcow> | rubys: yes :) |
| 16:09 | <rubys> | karlcow: ok, you have successfully demonstrated that the mac interoperates successfully with the mac. Congrats. :-) |
| 16:10 | <karlcow> | ;) |
| 16:11 | <karlcow> | firefox http://lagrange.test.site/2009/02/02/love-e%CC%81-%E6%84%9B.txt |
| 16:12 | <rubys> | the key here is that there are multiple ways to encode the e with a combining accent character. |
| 16:14 | <karlcow> | the way I do on my keyboard is typing the accent and the e because I'm on a Japanese keyboard. |
| 16:14 | <karlcow> | hmm I should switch to the French keyboard to see if there is any difference |
| 16:14 | <rubys> | no, it is more fundamental than that. |
| 16:14 | <rubys> | you have multiple ways to enter the same character, but there are multiple ways to encode that same character |
| 16:17 | <karlcow> | hmmm yep doesn't change anything |
| 16:17 | <rubys> | e with a combining accent is %CC%81 on mac, and %C3%A9 in utf-8. |
| 16:18 | <rubys> | utf-8 NFC that is. |
| 16:19 | <karlcow> | if I type manually on the mac the two %C3%A9 and %CC%81, I get back é |
| 16:19 | <karlcow> | (in the uri field) |
| 16:19 | <karlcow> | and the right content of the file |
| 16:20 | <ap> | %CC%81 is just the combining accent (U+0301 COMBINING ACUTE ACCENT) |
| 16:21 | <ap> | "e%CC%81" is LATIN SMALL LETTER E WITH ACUTE in decomposed form |
| 16:22 | <rubys> | ap: oops, you are correct. I dropped the e. |
| 16:26 | <Philip`> | OS X converts text to NFD (or NFC or whichever it is) before rendering it, which confused me when I was playing with fonts and expected it to use the glyphs for each codepoint of my original text, and actually it tried using totally new codepoints instead |
| 16:27 | <jgraham> | Are combing characters actually necessary or are they just an unfortunate artefact of old coding systems? That is is it possible to represent any string without using any combing characters at all? |
| 16:27 | <gsnedders> | jgraham: There are plenty of things that can't be |
| 16:27 | <jgraham> | gsnedders: I thought that would be the case :( |
| 16:28 | <Philip`> | jgraham: What is "any string"? |
| 16:28 | <Philip`> | jgraham: Would e.g. '@' with an acute accent be a string you'd want to be representable? |
| 16:29 | <jgraham> | Philip`: I knew someone would ask that and I had odds on that it would be you |
| 16:29 | <jgraham> | Philip`: No. I mean sequences of glyphs that are actually used in human languages and maybe mathematics |
| 16:30 | gsnedders | just took the definition of "any" to mean "any" |
| 16:30 | <jgraham> | Yes, sorry I was rather inprecise |
| 16:31 | <Philip`> | jgraham: I expect Vietnamese like http://www.microsoft.com/typography/otspec/fig4a.gif is done using combining characters, and it would be impractical to have a separate codepoint for every possible combination of base+marks |
| 16:31 | <karlcow> | I guess the dot for Japanese characters |
| 16:32 | <jgraham> | Philip`: Ah, that is exactly the answer to the question that I was really trying to ask |
| 16:32 | <Philip`> | jgraham: Whoops, that was an accident, I never intended to actually answer your question :-( |
| 16:33 | <jgraham> | So it seems like if you could keep only one normalisation it would have to be NFD and everything else would be char+combing char |
| 16:33 | <ap> | jgraham: that's what Unicode recommends |
| 16:33 | <ap> | sadly, it's not possible to achieve on the Web |
| 16:34 | <jgraham> | ap: Sure, I was talking hypothetically about the design choice that you would make with hindsight |
| 16:35 | <rubys> | it would bloat a lot of common use cases for latin-1 characters |
| 16:35 | <jgraham> | The fact that Unicode is messy indicates that it is useful |
| 16:36 | <ap> | rubys: relatively few people use latin-1 characters |
| 16:36 | <karlcow> | I wonder if the bōten is part of the composed characters issue or something different |
| 16:37 | <rubys> | ap: ? ... spanish, french, etc are all full of charcters with tilde's and combining acents. |
| 16:37 | jgraham | wonders what name people give to the strong version of the "worse is better" philosophy; that it is not possible for systems to be successful without having characteristics that are different from the solution that would, with hindsight, have been ideal |
| 16:37 | <ap> | rubys: what about Chinese, Japanese, Russian, Indic languages, Arabic... |
| 16:38 | <karlcow> | http://www.w3.org/TR/jlreq/ is a cool document |
| 16:38 | <jgraham> | s/ideal/better/ perhaps |
| 16:39 | <rubys> | karlcow: got python? |
| 16:41 | <rubys> | import unicodedata |
| 16:41 | <karlcow> | http://www.w3.org/TR/jlreq/#en-subheading2_3_9 emphasis dot |
| 16:41 | <karlcow> | rubys: yes |
| 16:41 | <rubys> | print repr(unicodedata.normalize('NFC', u'ō').encode('utf-8')) |
| 16:41 | <rubys> | print repr(unicodedata.normalize('NFD', u'ō').encode('utf-8')) |
| 16:42 | <rubys> | The results are '\xc5\x8d' and 'o\xcc\x84' respectively. |
| 16:45 | <karlcow> | indeed. :) cool thanks |
| 16:46 | <karlcow> | had to put in my python file # -*- coding: utf-8 -*- |
| 16:46 | <jgraham> | karlcow: Although if you start messing about with python+non BMP characters+normalisation, things could get very confusing fast |
| 16:47 | <jgraham> | (python can't decide if characters are 16bit or 32bit which causes observable brokenness) |
| 16:47 | <jgraham> | (in some cases) |
| 16:56 | <gsnedders> | jgraham: No, Python can decide whether. It's just a compile time option. |
| 16:56 | <gsnedders> | Which makes me want to stab it. |
| 16:57 | <karlcow> | stabbing a python that is not nice of you |
| 16:58 | <hallvors> | feedback (primarily from browser developers) on http://testsuites.opera.com/script-execution/ welcome .. |
| 17:07 | <ehird> | HTML5 obligates dates to use a hyphen (-). But more correct would be the figure dash (‒). What should I do? |
| 17:07 | <jgraham> | gsnedders: A compile time option meets my definition of "can't decide". |
| 17:08 | <gsnedders> | :) |
| 17:08 | <gsnedders> | Anolis has some rather horrible code for the one time when it cares about codepoints above U+FFFF |
| 17:09 | <ehird> | ? |
| 17:11 | <jgraham> | ehird: Either complain to Hixie and get it fixed or worry less about typography :) |
| 17:12 | <jgraham> | (seriously mail whatwg⊙wo; you'll need to subscribe to the list first) |
| 17:12 | <ehird> | jgraham: I understand the words "worry", "less", "about" and "typography" but the combination you have put them in simply does not parse in my mind ;-) |
| 17:12 | <ehird> | And OK, I'll do that |
| 17:12 | <ehird> | thanks :) |
| 17:15 | <gsnedders> | ehird: Off hand we use a hyphen because ISO 8601 does |
| 17:15 | <ehird> | gsnedders: Mm, makes sense, just would be nice to lax it a bit to, say, "any dash" |
| 17:16 | <gsnedders> | ehird: I'd say that's too lax |
| 17:16 | <jgraham> | ehird: Presumably "any" doesn't include ┋ |
| 17:16 | <jgraham> | for example |
| 17:16 | <ehird> | ok then - hyphen, e[mn]dash and figure dash? |
| 17:16 | <ehird> | :) |
| 17:17 | <ehird> | jgraham: It is 2009┋02┋02. |
| 17:17 | <gsnedders> | ehird: Why would we want to allow e[mn] dash, though? |
| 17:17 | <ehird> | Doesn't look that bad, actually. :P |
| 17:17 | <ehird> | gsnedders: En dash is more well supported than figure dash, and generally looks identical |
| 17:17 | <ehird> | em dash probably isn't worth it, though |
| 17:19 | <jgraham> | I totally want to write 2009⤐02⥭02 |
| 17:20 | <ehird> | Really, I'd just go for something like <date iso="2009-02-02">THINE SECOND DAY OF THINE SECOND MONTH (FEB-RU-ARY) OF THINE YEAR 2 0 0 9</date> |
| 17:22 | <jcranmer> | 2009•02·02? |
| 17:25 | <jgraham> | jcranmer: What are these dots that you use? |
| 17:25 | <jgraham> | We only support dashes here |
| 17:25 | <gsnedders> | ehird: s/iso/datetime/ |
| 17:25 | <ehird> | gsnedders: Oh, that exists? |
| 17:25 | <gsnedders> | ehird: yeah |
| 17:26 | <ehird> | Well then, I'll just use that. |
| 17:27 | <jgraham> | ehird: If your use case is the <time> element, you can always specify a datetime attribute with hyphens and have the text content be anything you like |
| 17:27 | <ehird> | There used to be a <date> element, was that renamed to time? |
| 17:28 | <gsnedders> | ehird: No |
| 17:29 | <ehird> | Okay, so it's still <date>. Does that have datetime too? |
| 17:29 | <gsnedders> | ehird: I mean, there never was a date |
| 17:29 | <ehird> | huh, okay |
| 17:29 | ehird | 's memory is going ;) |
| 17:30 | <gsnedders> | ehird: Why do you want a date element? |
| 17:30 | <ehird> | I don't |
| 17:30 | <ehird> | I just recall there being one |
| 17:30 | <gsnedders> | :P |
| 17:31 | <gsnedders> | ehird: There's dc:date, but no other element with "date" as a localname off-hand |
| 17:31 | <ehird> | OK :) |
| 17:47 | <karlcow> | ehird: you could do with <html xmlns:event="http://www.w3.org/2002/12/cal#">; |
| 17:47 | <karlcow> | <p>Karl will be away for lunch time today from |
| 17:47 | <karlcow> | <span property="event:dtstart" |
| 17:47 | <karlcow> | content="2009-02-02T13:00:00">1pm</span> |
| 17:47 | <karlcow> | to |
| 17:47 | <karlcow> | <span property="event:dtend" |
| 17:47 | <karlcow> | content="2009-02-02T14:00:00">2pm.</span></p> |
| 17:48 | <ehird> | :-) |
| 17:48 | karlcow | makes it effective now in fact :) |
| 18:15 | <krijnh> | For those into statistics: http://krijnhoetmer.nl/irc-logs/activity/whatwg/ |
| 18:19 | <Philip`> | krijnh: That doesn't work so well for me |
| 18:19 | <Philip`> | in Opera 9.6 |
| 18:19 | <Philip`> | (All the bars are about square, except for 200805 which is wider than the screen) |
| 18:26 | <krijnh> | Philip`: same here |
| 18:26 | <krijnh> | Especially for us Opera users there are numbers :) |
| 18:26 | <ehird> | works for me |
| 19:14 | <hsivonen> | the mac URI thing isn't a mac or linux problem per se. It's a problem of Apache letting a byte-orieted API leak to where users now expect characters |
| 19:17 | <rubys> | True to a point... in pretty much the same way that a statement that CSRF is not a security issue for the web, but is a problem in the browsers. |
| 19:59 | zcorpan_ | wonders why opera removes a line break after @namespace ...; in the rendering |
| 20:46 | <gsnedders> | Civ2 is an awesome game. |
| 20:46 | <jcranmer> | I've only played Civ3 |
| 20:47 | <gsnedders> | Civ2 is a lot better. |
| 21:13 | <yorick> | I'd like the offline web applications to have a dynamic whitelist |
| 21:15 | <yorick> | or just to access online stuff when online |
| 21:28 | <Hixie> | takkaria: i don't understand what you mean about 10.3.5. gsnedders: i don't understand what you mean by 10.4.1. |
| 21:29 | <gsnedders> | :D |
| 21:29 | <gsnedders> | Hixie: 10.4.1 says that LF within @title must be rendered as a linebreak, no? |
| 21:29 | <gsnedders> | s/must/are expected to/ |
| 21:31 | <gsnedders> | Hixie: Run //*[contains(@title, "\n")] on HTML 5 |
| 21:34 | <gsnedders> | Hixie: Matches 266 elements! |
| 21:36 | <Hixie> | oh, yeah, i know |
| 21:36 | <Hixie> | i'm abusing title="" in html5 |
| 21:36 | <gsnedders> | Hixie: http://pastebin.ca/1325718 |
| 21:36 | <Hixie> | really i should use data-anolis-xref or some such |
| 21:39 | <gsnedders> | Hixie: And Anolis should probably support some such :) |
| 21:41 | <Hixie> | yeah |
| 21:42 | <Hixie> | or just strip out the title=""s |
| 21:42 | <gsnedders> | That's not really nice though |
| 21:43 | <Hixie> | strip the line feeds? :-) |
| 21:44 | <gsnedders> | Hixie: But you might mean them! |
| 21:44 | <rubys> | Just checking, but undoubtedly you are familiar with how XML treats linefeeds in attribute values, right? |
| 21:44 | <Hixie> | gsnedders: i won't use title="" intentionally in the spec other than for xrefs |
| 21:44 | <gsnedders> | Hixie: I mean, what would xkcd be like without LF in @title!? |
| 21:44 | <Hixie> | rubys: yeah |
| 22:37 | <takkaria> | Hixie: 10.3.5 is rendering->simple defaults->fonts and colors |
| 22:41 | <Hixie> | right...? |
| 23:00 | <ehird> | http://ishtml5readyyet.com/ How ridiculously wrong. :P |
| 23:00 | <Hixie> | depends what you mean by "ready" |
| 23:00 | <ehird> | Well, I guess if you define "ready" as something other than "ready", it could be reasonable. |
| 23:02 | <Philip`> | Currently it's both ready and writey |
| 23:03 | <Hixie> | ehird: if by "ready" you mean "done, never to change again", then it's probably pretty accurate |
| 23:03 | <ehird> | That's "finished", not "ready", no? |
| 23:03 | <Hixie> | ehird: if by "ready" you mean "prepared for work to begin", then we're about 6 years past that point |
| 23:04 | <Hixie> | if you mean something in between, then, well, like i said. it depends on how you define "ready". |
| 23:04 | <ehird> | By "ready", I mean "heat death of the universe". :-) |
| 23:08 | <takkaria> | Hixie: http://rafb.net/p/OVlhvi87.html |
| 23:10 | <Hixie> | ooh. |
| 23:10 | <Hixie> | h2 is smaller than _h3_ |
| 23:10 | <Hixie> | you said h1. |
| 23:10 | <Hixie> | hence my confusion. |
| 23:15 | <takkaria> | oh, sorry |
| 23:15 | <takkaria> | :) |
| 23:15 | <takkaria> | the keys are right next to each other :) |
| 23:16 | <Hixie> | fixed :-) |
| 23:16 | <Hixie> | (not regenned yet) |
