| 01:03 | <othermaciej> | annevk: for WebKit we've always leaned more towards Gecko hacks than Trident hacks |
| 07:05 | <MikeSmith> | zcorpan_: I fixed the problems with obsolete-attribute checking you found yesterday |
| 07:05 | <MikeSmith> | when you have time, please check again and let me know if find anything else I've missed |
| 07:06 | <MikeSmith> | on http://qa-dev.w3.org:8888/ |
| 07:06 | <MikeSmith> | hsivonen: http://whattf.browse.cvsdude.com/syntax/trunk/non-schema/java/src/org/whattf/checker/schematronequiv/Assertions.java?r1=483&r2=486 |
| 07:06 | <MikeSmith> | lemme know if there are any other refinements I should make to that |
| 07:20 | <zcorpan_> | MikeSmith: <embed name> still gives the relaxng error |
| 07:21 | <zcorpan_> | MikeSmith: and <a urn> |
| 07:21 | <MikeSmith> | zcorpan_: thanks |
| 07:22 | <zcorpan_> | MikeSmith: and <input usemap> |
| 07:22 | <MikeSmith> | I didn't have those in my list at all |
| 07:22 | <MikeSmith> | zcorpan_: are you working from a list, or from memory? |
| 07:22 | <zcorpan_> | MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20091117#l-293 |
| 07:23 | MikeSmith | looks now |
| 07:24 | <MikeSmith> | OK |
| 07:24 | <MikeSmith> | I was working from annevk HTML4-HTML5 differences doc |
| 07:25 | <zcorpan_> | html5 lists some attributes as obsolete that were already obsolete or not even mentioned in html4 |
| 07:25 | <MikeSmith> | ok |
| 07:26 | <MikeSmith> | I will go through your test case and add everything that's missing |
| 07:27 | zcorpan_ | reserves the right to have made mistakes in his testcase and suggests MikeSmith looks at the spec from which the test was created |
| 07:27 | <MikeSmith> | hai |
| 08:28 | <MikeSmith> | zcorpan_: embed was never officially part of any published version of HTML before HTML5, right? |
| 08:28 | <Hixie> | right |
| 08:33 | <MikeSmith> | just wondering about whether v.nu actually should report name and align attributes on it as obsolete |
| 08:33 | <MikeSmith> | but I guess it should |
| 08:33 | <MikeSmith> | given that despite it not being part of any published standard, we still want to give useful warnings about it |
| 08:36 | <zcorpan_> | MikeSmith: btw, the spec has suggestions for what to use instead, would be cool if the validator used them in the messages |
| 08:36 | <zcorpan_> | sorry if i'm stating the obvious :) |
| 08:37 | <MikeSmith> | zcorpan_: yeah, I see that now. but would rather wait til later to add that. it would take significantly more time to add it right now |
| 08:38 | <zcorpan_> | ok |
| 09:10 | <MikeSmith> | zcorpan_: OK, please try again when you have time |
| 09:10 | <MikeSmith> | on http://qa-dev.w3.org:8888/ |
| 09:10 | <MikeSmith> | I don't actually know how to run your test case myself |
| 09:11 | <MikeSmith> | because I don't know how to make v.nu use data: URIs |
| 09:11 | annevk2 | curses people with loud car/door/something alarms |
| 09:12 | <annevk2> | and especially those that let them go off so many times people can no longer sleep |
| 09:13 | <MikeSmith> | zcorpan_: I get an error on the console, "unsupported protocol: 'data'" |
| 09:16 | <zcorpan_> | MikeSmith: i just copied the text into the textarea |
| 09:19 | <zcorpan_> | MikeSmith: i still get the relaxng error for <input usemap> |
| 09:20 | <MikeSmith> | shit |
| 09:20 | <MikeSmith> | lemme check |
| 09:21 | <MikeSmith> | ah yeah |
| 09:22 | <zcorpan_> | MikeSmith: maybe the messages should say "The foo attribute on element bar is obsolete" instead of just "The foo attribute is obsolete" since e.g. <link target> is obsolete but <a target> isn't |
| 09:22 | gsnedders | finds a page which behaves differently with %26 and & in the URI |
| 09:22 | <MikeSmith> | there's not a single attribute pattern for the input element in the scheme |
| 09:22 | <MikeSmith> | *schema |
| 09:23 | <MikeSmith> | zcorpan_: yeah, I guess we should have it do that |
| 09:23 | <zcorpan_> | the schema adds attributes depending on what type is, doesn't it? |
| 09:23 | <zcorpan_> | for input |
| 09:23 | <MikeSmith> | yeah |
| 09:24 | <MikeSmith> | so that means I have to add it to 20 different patterns |
| 09:24 | <zcorpan_> | isn't there input.attrs.common or so? |
| 09:24 | <MikeSmith> | maybe |
| 09:24 | <MikeSmith> | I can't remember.. I'll look |
| 09:25 | <zcorpan_> | i guess usemap was only valid for type=image anyway |
| 09:25 | <zcorpan_> | so you could just add it to type=image and leave the rest |
| 09:26 | <MikeSmith> | yeah, true |
| 09:27 | <zcorpan_> | s/valid/used/ |
| 09:27 | <MikeSmith> | anyway, fwiw, there is no input.attrs.common pattern (or equivalent) -- I guess because there are no attributes common to all input elements that aren't also common too all form attributes (or that aren't global on all elements) |
| 09:28 | <othermaciej> | isn't "type" common to all form elements? |
| 09:28 | <othermaciej> | er, to all inputs I mean, but not other form elements? |
| 09:29 | <zcorpan_> | othermaciej: yes, but since the schema has different patterns depending on type, that's not particularly helpful in this case |
| 09:29 | <annevk2> | depends, all form elements do have a type IDL attribute |
| 09:29 | othermaciej | has no idea what the context is, just sayin' |
| 09:32 | <zcorpan_> | MikeSmith: also <object code> |
| 09:33 | <MikeSmith> | zcorpan_: that one I omitted intentionally.. because afaict no published spec ever allowed code on object anyway |
| 09:33 | <MikeSmith> | do people actually use code on object? |
| 09:33 | <MikeSmith> | I thought it was just for applet |
| 09:33 | <MikeSmith> | I wasn't sure if it was included in the list intentionally or not |
| 09:33 | <zcorpan_> | MikeSmith: dunno, maybe the spec is wrong in listing <object code> as obsolete |
| 09:34 | <zcorpan_> | same for <param type>? |
| 09:35 | MikeSmith | checks on <param type> |
| 09:36 | <zcorpan_> | MikeSmith: also align on input |
| 09:36 | <MikeSmith> | ah yeah |
| 09:36 | <zcorpan_> | MikeSmith: gives 2 messages |
| 09:37 | <MikeSmith> | that I will need to add to a lot more patterns |
| 09:38 | <jgraham> | hsivonen: I wouldn't expect the DOM to depend on network packet boundaries |
| 09:38 | <zcorpan_> | hmm, html4 doesn't have <input align> |
| 09:39 | <zcorpan_> | oh but html 3.2 does |
| 09:41 | jgraham | wonders if we have reached any conclusion about coalescing text nodes in general |
| 09:41 | <zcorpan_> | MikeSmith: maybe the message for <img border=1> and <script language=vbscript> should advice to use the preferred alternative instead of advicing to alter the value |
| 09:43 | <MikeSmith> | zcorpan_: the warnings for those cases basically come directly from what's mandated in the spec |
| 09:43 | <MikeSmith> | I think |
| 09:43 | <MikeSmith> | it looks like html4 loose allowed <param type> |
| 09:43 | <zcorpan_> | MikeSmith: yes, but if you have <script language=vbscript>, you don't want to change that to <script language=javascript> |
| 09:44 | <zcorpan_> | MikeSmith: because presumably the script was vbscript and language is still obsolete so changing the value still won't silence the validator |
| 09:44 | <zcorpan_> | MikeSmith: it should advice to use <script type=text/vbscript> |
| 09:44 | <MikeSmith> | zcorpan_: right, I see what you're saying now |
| 09:44 | <MikeSmith> | please file a bug on that one if you have time |
| 09:49 | <zcorpan_> | MikeSmith: no message for <ul><li type> and <ol type> and <ul type> |
| 09:53 | <MikeSmith> | hmm, that one's weird |
| 09:57 | <MikeSmith> | zcorpan_: no clue on that one yet.. code seems right |
| 09:58 | <MikeSmith> | but I'll check in the other changes shortly |
| 09:58 | <MikeSmith> | ah, found it |
| 09:59 | <MikeSmith> | (dumb mistake) |
| 10:17 | <annevk2> | http://www.w3.org/mid/JACATK.TNKL0CLX3OQC⊙ac is somewhat interesting |
| 10:17 | <annevk2> | browser vendors abused the SVG WG |
| 10:17 | <annevk2> | heard it here first |
| 10:26 | <othermaciej> | cause we're mean |
| 10:27 | <MikeSmith> | the SVG WG was guilty of self-abuse |
| 10:45 | <othermaciej> | Opera supports the uDOM? |
| 10:46 | <annevk2> | unfortunately yes |
| 10:46 | <annevk2> | hopefully nobody else adds it |
| 10:47 | <othermaciej> | seems like it is on the active disinterest list for WebKit and Gecko at least |
| 10:49 | <annevk2> | yeah |
| 10:49 | <othermaciej> | SVG Tiny 1.2 is a REC? now that's an implementation report I gotta read |
| 10:50 | <annevk2> | not sure how that worked either; hopefully now more browsers are involved the next SVG will be better |
| 10:50 | <zcorpan_> | "The only way to have features put into SVG or any other W3C |
| 10:50 | <zcorpan_> | spec is to participate in the group, attend teleconferences, |
| 10:50 | <zcorpan_> | face to face meetings and back your cause." |
| 10:51 | <othermaciej> | hmm the implementation report doesn't seem to include even a single implementation passing all the tests |
| 10:52 | <othermaciej> | ah, I see |
| 10:52 | <othermaciej> | their "two implementations" requirement is per test |
| 10:53 | <zcorpan_> | so i can write an implementation that passes one test, and it would count? |
| 10:55 | <annevk2> | you'd need another |
| 10:55 | <jgraham> | Allowing partial implementations as evidence that the spec as a whole is implementable seems like it has obvious flaws |
| 10:56 | <annevk2> | i guess in the trade-off perfection vs moving forward they picked moving forward |
| 10:56 | <othermaciej> | "The CR exit criteria were a minimum of two implementations passing each test in the test suite, of which at least one must be running on a mobile platform." |
| 10:56 | zcorpan_ | writes an impl that does nothing but showing "PASS", which magically passes lots of tests |
| 10:57 | <othermaciej> | that first clause is ambiguous |
| 11:00 | <othermaciej> | I don't see why they tested Firefox or Safari (they only "passed" two tests total) but it looks like they needed all of the other 8 implementations tested to meet their CR exit criteria |
| 11:03 | <othermaciej> | interesting to see Microsoft following SVG |
| 11:05 | Philip` | wonders if anyone has worked out the historical correlation between Microsoft commenting on details of specs and them implementing it in the next version of IE |
| 11:08 | <MikeSmith> | zcorpan_: I checked in several changes and I think fixed the misses you've reported so far |
| 11:09 | <MikeSmith> | except for object/@code, which I'm still not sure whether that's in the list intentionally or inadvertently |
| 11:10 | <zcorpan_> | MikeSmith: file a spec bug on object code |
| 11:10 | <MikeSmith> | OK |
| 11:10 | <MikeSmith> | I'm looking for MAMA on that one too |
| 11:12 | <MikeSmith> | no @code in http://dev.opera.com/articles/view/mama-plug-ins/#object |
| 11:13 | <MikeSmith> | but then, @codetype didn't make that list either |
| 11:16 | <Philip`> | I see several <object codetype>s in dotbot data |
| 11:17 | <Philip`> | and zero <object code>s |
| 11:17 | <Philip`> | (By "several" I mean about a dozen sites) |
| 11:25 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cobject%20id%3Do%3E%3C%2Fobject%3E%3Cscript%3Edocument.getElementById%28%27o%27%29.code%3D1%3C%2Fscript%3E - hmm, browsers support it |
| 11:26 | <Philip`> | http://google.com/codesearch?q=%3Cobject%5B%5E%3E%5D%2A%5Cscode%3D - some people use it |
| 11:35 | <gsnedders> | Anyone know what sort of feedback MS have been sending on SVG? I heard a bit from ed over lunch, but anyone know what sort of stuff specifically? General technical issues? Stuff you'd find during implementing? |
| 11:35 | <MikeSmith> | Philip`: thanks. I moved the bug to resolved=invalid |
| 12:00 | <hsivonen> | the SVG post is interesting |
| 12:05 | <annevk2> | https://bugzilla.mozilla.org/show_bug.cgi?id=526491#c5 hmm, Brendan seems somewhat pissed off with our specs :/ |
| 12:47 | <jgraham> | annevk2: No, really? |
| 12:49 | zcorpan_ | notes that his suggestion of prefixing x3d elements with "x" would result in an element called <xbox> |
| 12:54 | <othermaciej> | the latest Editor's Draft of Web IDL does seem to specify that there should be a "constructor" property, but it's not very specific about location |
| 12:56 | <othermaciej> | (last WD does not mention it) |
| 12:56 | <othermaciej> | in any case I'd doubt Blake even looked there |
| 12:57 | <othermaciej> | I am not sure why Brendan seems to have a bee in his bonnet lately |
| 12:58 | <annevk2> | btw, jgraham told me in some other channel we did actually recently reverse engineer Date parsing to improve compatibility |
| 12:58 | <annevk2> | gotta love that |
| 12:58 | <Dashiva> | I'm more surprised you didn't do it earlier |
| 12:58 | <Dashiva> | Since that's one of the worst parts of the es3 spec |
| 12:59 | <othermaciej> | I'm sure JavaScriptCore is full of reverse engineering hackery on that front |
| 12:59 | <gsnedders> | We didn't reverse-engineer it in a massive amount of detail though |
| 12:59 | <othermaciej> | Brendan has long cited it as an example of something that should not be spec'd at all ever (back to the ES3.1 vs ES4 days) |
| 12:59 | <annevk2> | Dashiva, I'm sure we did it several times |
| 12:59 | <Dashiva> | btw: Do you really need to reverse engineer, considering both FF and Safari are open source? :) |
| 12:59 | <othermaciej> | I never quite grasped his explanation of why though |
| 13:00 | <annevk2> | dhyatt claimed for a while that defining the HTML parser would not be possible |
| 13:00 | <Dashiva> | othermaciej: Maybe he's in the "Only specify good and decent behavior" camp? |
| 13:00 | <annevk2> | (and it is indeed somewhat insane) |
| 13:01 | <othermaciej> | Dashiva: the thing is, he's been on the "face the lame reality" side in other cases |
| 13:02 | <othermaciej> | hyatt was very nearly right! |
| 13:03 | <Dashiva> | But impossible just means it takes longer :P |
| 13:03 | <othermaciej> | it seems like the most ES-like thing to do would be for the constructor property to be on the prototype |
| 13:05 | <othermaciej> | that's what happens for built-in objects and for objects created by JS-implemented constructors |
| 13:41 | <Dashiva> | >Flight to #TPAC09: $3300, Hotel: $1800 |
| 13:41 | <Dashiva> | That's... a lot more than I would expect |
| 13:42 | <annevk2> | those are not the real numbers I think |
| 13:42 | <annevk2> | I hope so anyway! |
| 13:45 | <Lachy> | annevk2, if you add up the costs of all the hotels we stayed in for the whole time in the US, it comes fairly close to $1800 for the 3 of us |
| 13:46 | <Lachy> | same for our combined flight costs |
| 13:49 | <annevk2> | oh, combined |
| 13:50 | <annevk2> | it should say flights then |
| 13:50 | <annevk2> | etc. |
| 13:54 | <annevk2> | lol |
| 13:54 | <annevk2> | http://vimeo.com/6985053 |
| 13:54 | <annevk2> | check two minutes in |
| 14:12 | <gsnedders> | annevk2: I can't watch that. It needs Flash. Can you give me a version which I can view? |
| 14:13 | <annevk2> | no |
| 14:14 | <gsnedders> | Then you fail. |
| 14:15 | <Philip`> | gsnedders: On the contrary, it seems to be you who is experiencing the failure |
| 14:18 | <murr4y> | "you shall go to the pub, cinderella" |
| 14:18 | <murr4y> | pure gold :D |
| 14:26 | <jgraham> | Dashiva: Where are those numbers from? |
| 14:26 | <annevk2> | |
| 14:34 | <MikeSmith> | that mack from brucel presentation should become the official logo for HTML5 |
| 14:34 | <MikeSmith> | "HTML5: HTML, but with more pimp cane" |
| 14:35 | murr4y | agrees |
| 14:54 | <MikeSmith> | zcorpan_: error messages for obsolete attributes now also include the element names |
| 14:54 | <MikeSmith> | per your suggestion |
| 15:00 | <zcorpan_> | MikeSmith: cool |
| 15:07 | <MikeSmith> | zcorpan_: so I want to also implement your suggestion about the error messages including suggestions about what to use instead, but I need to figure out how best to do it |
| 15:08 | <zcorpan_> | MikeSmith: for <script language> or in general? |
| 15:08 | <MikeSmith> | in general |
| 15:08 | <MikeSmith> | right now the obsolete-attributes stuff is in a hash table where the attribute name is the key and the array of elements on which it's obsolete is the value |
| 15:09 | <MikeSmith> | so what I'd need to do is also associate a string with the suggestion about what to use instead |
| 15:10 | <zcorpan_> | MikeSmith: <p align> says "The align attribute on the p element is obsolete. Use CSS instead." |
| 15:10 | <MikeSmith> | zcorpan_: yeah.. is that wrong? |
| 15:10 | <zcorpan_> | no |
| 15:11 | <zcorpan_> | how is the "Use CSS instead." implemented? |
| 15:11 | <MikeSmith> | it's just boilerplate for the case of all attributes that are presentational |
| 15:12 | <zcorpan_> | can you use a similar approach for other groups of attributes? |
| 15:13 | <MikeSmith> | the code has broad conditions (two separate hash tables): one for the set of "presentational" attributes, and one for the others |
| 15:13 | <MikeSmith> | the others don't really fall into any recognizable patterns/groups |
| 15:14 | <zcorpan_> | ok |
| 15:14 | <MikeSmith> | so would need to have some message string associated for each attribute |
| 15:15 | <MikeSmith> | even then, that'd also assume that the "what to use instead" suggestion is one-to-one the same for a particular attribute, regardless of what the element is.. which I'm not sure is actually the case |
| 15:15 | <MikeSmith> | anyway, I'll look at it some more |
| 15:16 | <MikeSmith> | it would be worthwhile to try to capture/report all the info/suggestions that's available in the spec |
| 15:17 | <zcorpan_> | the spec doesn't seem to have different suggestions for attributes with the same name |
| 15:17 | <MikeSmith> | Ok, that's good at least |
| 15:18 | <MikeSmith> | that makes it a lot easier |
| 15:23 | <MikeSmith> | I guess I could just use two separate hash tables for each attribute: one table that associates each attribute with a list of one or more elements on which it's obsolete, and another table that associates each attribute with a "what to use instead" message |
| 15:24 | MikeSmith | looks around for hsivonen |
| 15:24 | hsivonen | looks at the scrollback |
| 15:25 | <hsivonen> | is what to use instead unique by attribute name or do you need both the attribute and the element name? |
| 15:25 | <MikeSmith> | hsivonen: just by attribute name |
| 15:25 | <hsivonen> | ok. I guess hashtables like that will work |
| 15:27 | hsivonen | leaves the computer having blogged about http://hsivonen.iki.fi/speculative-html5-parsing/ |
| 15:27 | <Philip`> | <ul type> |
| 15:28 | <Philip`> | <param type> |
| 15:28 | <Philip`> | Spec gives different suggestions for those |
| 15:28 | <zcorpan_> | ul type is in the presentational bucket |
| 15:29 | <Philip`> | Ah |
| 15:29 | <zcorpan_> | but it does mean that MikeSmith can't combine the currently presentational hashtable and the-rest hashtable into one |
| 15:29 | <MikeSmith> | right |
| 15:30 | <MikeSmith> | I did it that way because the spec makes that same high-level distinction |
| 15:30 | <MikeSmith> | as does annevk2 differences doc |
| 15:30 | <MikeSmith> | and because it seems like a useful broad distinction |
| 15:30 | Philip` | imagines it would be nice if the validator gave more specific advice for common situations, like if people do ugly <object> plugin stuff then it should suggest specific equivalent non-obsolete markup to achieve the same effect |
| 15:30 | Philip` | wonders if that kind of thing could be possible |
| 15:31 | <Philip`> | (Ideally it would give specific CSS suggestions for presentational attributes, too) |
| 15:32 | <Philip`> | (because otherwise it's really hard trying to remember what the equivalent of <table cellpadding=0 cellspacing=0 border=1> is) |
| 15:32 | <zcorpan_> | "Use CSS instead" could be a link to http://wiki.whatwg.org/wiki/Presentational_elements_and_attributes |
| 15:33 | <MikeSmith> | that's doable, I think |
| 15:34 | <MikeSmith> | (the link, I mean) |
| 15:34 | <MikeSmith> | specific suggestions for each one is less doable |
| 15:34 | <MikeSmith> | ..because there are shitload of these |
| 15:35 | <Philip`> | Maybe not for all of them, just for the ones that turn out to be common and that cause people to post on forums saying "The validator says my code's wrong but I don't understand its scary messages, what should I do instead?" |
| 15:36 | <MikeSmith> | "suck it in" |
| 15:36 | <MikeSmith> | "get a clue" |
| 15:36 | <Philip`> | I'm assuming you want to actually help users, but I could be mistaken :-) |
| 15:36 | <zcorpan_> | "follow the link in the message" |
| 15:36 | <MikeSmith> | "give up and go back to developing is visual basic" |
| 15:50 | <pixeL`MBP> | is 2x <aside></aside> |
| 15:50 | <pixeL`MBP> | allowed? |
| 15:58 | <zcorpan_> | pixeL`MBP: yes |
| 15:58 | <pixeL`MBP> | ok |
| 17:55 | <zcorpan_> | gsnedders: does it work in ie? |
| 17:55 | <Philip`> | http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at-ie9-for-developers.aspx |
| 17:55 | <gsnedders> | zcorpan_: Yes, because IE displays fall-back content as it doesn't support SVG :P |
| 17:57 | <Philip`> | Looks like IE9 JS performance is no longer an order of magnitude off everybody else's |
| 17:58 | <zcorpan_> | gsnedders: hmm. i'm pretty sure there are sites that depend on the ie behavior of <object> scoping |
| 17:58 | <gsnedders> | I think we're screwed either way |
| 17:59 | <zcorpan_> | yes |
| 17:59 | <zcorpan_> | OTW |
| 18:01 | <TabAtkins> | otw? |
| 18:02 | <zcorpan_> | http://my.opera.com/downloadthefuture/blog/show.dml/2241145 |
| 18:03 | <zcorpan_> | uh, seems like http://my.opera.com/community/openweb/info/ is the appropriate reference |
| 18:05 | <gsnedders> | zcorpan_: bratell already filed |
| 18:10 | <GPHemsley> | Hixie: Out of curiosity, when does work on Acid4 begin? (Feel free to use the abstract HTML5 timeline as a reference point.) |
| 18:12 | <zcorpan_> | "Acid3 tests about 100 aspects of different technologies (many still in the “working draft” stage of standardization)" |
| 18:13 | <zcorpan_> | i thought it only tested things from specs that were in CR a few years ago |
| 18:13 | <GPHemsley> | zcorpan_: A commenter makes a note of that |
| 18:15 | <gsnedders> | GPHemsley: Once IE passes Acid4 |
| 18:15 | <gsnedders> | *Acid3 |
| 18:15 | <GPHemsley> | gsnedders: Somehow, I doubt that. |
| 18:15 | <gsnedders> | GPHemsley: What, the Acid4? :P |
| 18:16 | <GPHemsley> | -_- |
| 18:17 | <GPHemsley> | (that was a glare, BTW) |
| 18:19 | <gsnedders> | Yeah, we'll write Acid4 once IE passes it! |
| 18:19 | <gsnedders> | Why not? |
| 18:19 | <gsnedders> | :P |
| 18:20 | <GPHemsley> | lol |
| 18:22 | <AryehGregor> | Philip`, well, the point is that I was trying to see if everyone was okay with XML5 as long as we didn't claim it was XML. Whether you could actually output equivalent XML in all cases is somewhat academic. |
| 18:24 | <AryehGregor> | It seems like nobody actually cares about well-formedness as long as you avoid the term "XML". |
| 18:25 | <AryehGregor> | jgraham, flat-screen monitors were invented when they managed to get the dwarfs to go on a diet. It's true. |
| 18:27 | <zcorpan_> | "Not XML"? |
| 18:27 | <AryehGregor> | YML would be appropriate, since Y > X. However, it might be confused with YAML. Perhaps ZML? Z is almost as cool as X. |
| 18:28 | <zcorpan_> | Z for zcorpan? |
| 18:28 | <AryehGregor> | Maybe if you write the spec. |
| 18:29 | AryehGregor | is impressed that the IE Blog is honest enough to include other browsers' nightly builds in their blog post -- almost nobody does that |
| 18:29 | <AryehGregor> | "Hey, look, our bleeding-edge code is better than our competitors were six months ago!" |
| 18:30 | gsnedders | is amazed they got that post past middle-management |
| 18:30 | <AryehGregor> | (Or worse than our competitors were a year ago, in this case. But only slightly.) |
| 18:30 | <gsnedders> | The fact the developers are willing to admit they are behind and are playing to catch up having not had a browser under development for five years is quite obvious just speaking to any of them. |
| 18:32 | <AryehGregor> | It should be scary to everyone else, of course. IE5-6 clobbered the competition by leveraging vast sums of money so nobody could compete. Although monetarily, Google and Apple will be a lot tougher to outspend than Netscape, especially since they share a lot of the effort. |
| 18:32 | AryehGregor | foresees major benefits to consumers -- yay competition! |
| 18:32 | AryehGregor | refrains from drawing any kind of analogy to contentious political issues of the moment |
| 18:33 | <zcorpan_> | hmm, <applet> is scoping in firefox, but </span> still closes applet |
| 18:35 | <zcorpan_> | do we need to make span magic? |
| 18:37 | <zcorpan_> | <object> is scoping in webkit but </h3> still closes object |
| 18:37 | <zcorpan_> | should we make h1-h6 magic instead? |
| 19:04 | <zcorpan_> | gsnedders: ie7 actually doesn't show fallback for that page |
| 19:04 | <zcorpan_> | gsnedders: does ie8? |
| 20:08 | <foolip> | where did the WHATWG name come from? I seem to recall reading minutes from http://www.w3.org/2004/04/webapps-cdf-ws/ where Hixie asks something like "what working group will develop HTML?" Is that where it came from? |
| 20:10 | <Philip`> | foolip: That was on his blog |
| 20:10 | <foolip> | href? |
| 20:11 | <Philip`> | http://ln.hixie.ch/?start=1086387609&count=1 |
| 20:12 | <foolip> | thanks |
| 20:12 | <Philip`> | That was the same day the WHATWG was announced |
| 20:12 | <Philip`> | so I assume the name came earlier |
| 20:12 | <foolip> | given the italics, seems like it wasn't a coincidence at all |
| 20:13 | <Philip`> | Given the lack of "?" too |
| 20:14 | <foolip> | Philip`: no plan on upgrading http://philip.html5.org/demos/microdata/demo.html ? |
| 20:16 | <Philip`> | It's not something I have a plan to work, and not something I plan to plan to work on either, since it doesn't really seem worthwhile |
| 20:16 | <Philip`> | and since hopefully someone else will write a better one ;-) |
| 20:18 | <foolip> | may I copy paste at will? |
| 20:19 | <Philip`> | Please do |
| 20:21 | <Philip`> | though I disclaim all responsibility if someone uses anything derived from my code to parse microdata in order to remotely control an army |
| 20:24 | <foolip> | Philip`: naturally |
| 20:46 | <zcorpan_> | "There's only one rule for making speculative loads of linked scripts, style sheets and images succeed" - https://developer.mozilla.org/en/Optimizing_your_pages_for_speculative_parsing |
| 20:46 | <zcorpan_> | that's not quite true, since <link rel=" stylesheet" ...> fails |
| 22:27 | <Lachy> | annevk, if I'm reading the XML5 algorithm correctly, it seems that whitespace at the beginning of a file would trigger parse errors in the start phase of tree construction. I'm assuming that's unintentional |
| 22:39 | <annevk> | I would not waste time on XML5 |
| 22:39 | <annevk> | there's far more important things to worry about |
| 23:31 | <cying> | http://toki-woki.net/p/scroll-clock/ |
| 23:44 | <roc> | uh |
| 23:44 | <TabAtkins> | Haha, awesome. |