| 00:27 | <vlad_> | anyone have an opinion here on https://bugzilla.mozilla.org/show_bug.cgi?id=424386 ? this is screen.colorDepth and screen.pixelDepth returning 24 instead of 32 like they do now |
| 00:28 | <annevk> | the spec actually suggests 8... |
| 00:29 | <annevk> | so it should prolly be fixed |
| 00:36 | <Philip`> | "While I'm not convinced that many people are using this property ..." - actually, loads of people are using it |
| 00:36 | <Philip`> | like about 3% of pages from dmoz.org, if I'm counting right |
| 00:37 | <Philip`> | (mostly in stat-collecting scripts, not actually doing anything productive in the page itself) |
| 00:40 | <Dashiva> | Should lead to amusing trends in the graphs if the change goes through |
| 00:41 | <Philip`> | http://www.thecounter.com/stats/2008/March/colors.php - 24-bit isn't very popular now |
| 01:19 | <Hixie> | christ, editing 12MB files is a pain in the ass |
| 01:20 | <Dashiva> | What's the mozilla announcement Tyler Close was talking about with regard to XDR/XXX? |
| 01:22 | <Hixie> | ok i'm up to over 29000 parse errors in this 12mb file already |
| 01:22 | <Hixie> | (though in defense of the file, it's not an html file.) |
| 01:23 | <andersca> | is it a css file |
| 01:23 | <Lachy> | what file is it? |
| 01:23 | <Philip`> | Is it an MP3 file? |
| 01:23 | <Hixie> | it's http://trec.nist.gov/data/qa/T9_QAdata/qrels.trec9.qa.gz |
| 01:23 | <Hixie> | which for some reason makes my parser take 90 minutes |
| 01:23 | <Hixie> | when most pages take a few milliseconds |
| 01:24 | <Hixie> | and when you're parsing billions of pages, a page taking 90 minutes can really ruin your day |
| 01:24 | Philip` | suggests timeouts |
| 01:25 | <annevk> | is that a page? |
| 01:25 | <Hixie> | for reasons i won't go into, timeouts won't work for me |
| 01:25 | <annevk> | I get a download dialog |
| 01:25 | <Hixie> | annevk: it's a gzipped text file |
| 01:25 | <Hixie> | i wouldn't normally try to parse it, but for this mathml study i told my parser to ignore mime types |
| 01:26 | <Lachy> | that's a 30MB file, not 12 |
| 01:28 | <Hixie> | it's possible i truncated it at some point |
| 01:29 | Philip` | didn't realise TREC QA systems were so rubbish at trying to answer questions |
| 01:30 | <Philip`> | (The lines starting with 201 are all meant to be answers to "What was the name of the first Russian astronaut to do a spacewalk?") |
| 01:30 | <MikeSmith> | Hixie - can I get a copy of the script you're using for echoing HTML5 commit messages to twitter? |
| 01:30 | <MikeSmith> | I want to try to set up something similar for another project |
| 01:31 | <Hixie> | sure, hold on |
| 01:31 | <Hixie> | MikeSmith: e-mail? |
| 01:32 | <MikeSmith> | Hixie - yeah, please to mike⊙wo |
| 01:34 | <Hixie> | sent |
| 01:36 | <MikeSmith> | Hixie - thanks |
| 01:51 | <othermaciej> | man people love to say AC is insecure without giving specifics |
| 02:27 | <Hixie> | ok wtf |
| 02:27 | <Hixie> | randomly half way through this parse, my tokeniser goes into the mode where it outputs space characters separately from normal text |
| 02:38 | <Hixie> | othermaciej: i already replied to the cited e-mail |
| 02:38 | <Hixie> | othermaciej: there's nothing of substance in the claims in those e-mails |
| 04:13 | <othermaciej> | Hixie: I feel obligated to do my own analysis after calling the guy out like that, but you can trust that I understand security analysis reasonably well |
| 05:45 | <Hixie> | othermaciej: i would be happy to see a further analysis of his claims |
| 05:45 | <Hixie> | after all, maybe i made a mistake :-) |
| 05:45 | <othermaciej> | Hixie: my life is so full of tense email conversations right now |
| 05:45 | <Hixie> | join the club |
| 05:45 | <Hixie> | i was impressed at your handling of the forms task force issue |
| 05:46 | <Hixie> | i'm not sure i would have shown as much restraint |
| 05:46 | <othermaciej> | haha |
| 05:46 | <Hixie> | in the fact of such blatent process abuse |
| 05:47 | <othermaciej> | being a manager has taught me to show grace in the face of adversity |
| 05:47 | <Hixie> | i've learnt that lesson too, i'm just not good at remembering to do it :-) |
| 07:53 | <Hixie> | sigh, imply end tags for mathml is far too complex |
| 09:17 | <Hixie> | http://wiki.whatwg.org/wiki/New_Vocabularies_Solution are some scrap notes of what i think will work |
| 09:24 | <hsivonen> | Hixie: you haven't yet shown that my suggestion combined with Simon's wouldn't work |
| 09:25 | <hsivonen> | Hixie: though the "in math content" thing looks promising |
| 09:29 | <Hixie> | i thought i replied to you and simon |
| 09:29 | <hsivonen> | I wonder how hard it would be to write an HTML5 proxy using the Validator.nu parser and an XML serializer |
| 09:30 | <hsivonen> | Hixie: I analyzed all the problem cases you mentioned and showed they aren't show-stoppers |
| 09:30 | <hsivonen> | they are all quite harmless, actually |
| 09:30 | <Hixie> | ah, i haven't checked my mail recently |
| 09:30 | <Hixie> | (i'm skeptical of downplaying these issues, though) |
| 09:35 | <hsivonen> | Hixie: since you have a closed list of SVG elements, are you going to allow case-insesitivity in SVG? |
| 09:36 | <hsivonen> | eww. what's the deal with SVG using the hyphen sometimes and camelCase other times? |
| 09:36 | <Hixie> | my current plan, obviously open to discussion as is all of this, is to make the tokeniser case-insensitive as it is now, and to canonicalise the SVG tags to their propercase in the tree constructor |
| 09:37 | <Hixie> | it has camelCase, hyphenated-words, half-acronym tag names (e.g. hkern), full acronym tag names (e.g. svg), abbreviated words (e.g. defs), combinations of abbreviated and hyphenated (definition-src)... |
| 09:37 | <Hixie> | svg is a mess |
| 09:37 | <Hixie> | at least as bad as html |
| 09:37 | <hsivonen> | ok. (I think the right way implementation-wise is to canonicalize them in a custom string interning function) |
| 09:37 | <Hixie> | (yet it was designed by one committee, instead of 18 years of market forces) |
| 09:37 | <Hixie> | how do you mean? |
| 09:38 | <hsivonen> | to save memory and to make string equality compares memory pointer tests, it is good to have one canonical string object for each known tag name |
| 09:38 | <Hixie> | one problem is that with SVG 1.2 the tokeniser can't easily know the difference between <textarea> (html) and <textArea> (svg) |
| 09:38 | <Hixie> | yes i know what string interning is :-) |
| 09:39 | <Hixie> | but i mean, when would you do that? |
| 09:39 | <hsivonen> | ah |
| 09:39 | <hsivonen> | sorry |
| 09:39 | <hsivonen> | take the lower-case name buffer as input to the interning function but return a camelCase string |
| 09:39 | <Hixie> | in the svg insertion mode? |
| 09:40 | <hsivonen> | but even better, the return value could be an object that has the interned string *and* a magic int for doing a switch on in the tree builder |
| 09:40 | <hsivonen> | I'd do this in the tokenizer immediately before emitting the token to the tree builder |
| 09:41 | <othermaciej> | you need a case-insensitive string --> qname hashtable |
| 09:41 | <Hixie> | how would you handle name clashes then? |
| 09:41 | <Hixie> | the name clashes are what screw it up for me |
| 09:41 | <othermaciej> | but I guess it has to be context-sensitive |
| 09:41 | <Hixie> | yeah |
| 09:41 | <hsivonen> | the interning function would need to know if we are in an SVG or HTML context, yes |
| 09:41 | <hsivonen> | which would suck |
| 09:42 | <hsivonen> | the only string clash is textArea, isn't it? |
| 09:42 | <hsivonen> | and that's not supported by browsers is it? |
| 09:42 | <Hixie> | there are several clashes, but that's the only one that is affected by case |
| 09:43 | <Hixie> | i just omitted it from my proposal |
| 09:43 | <Hixie> | but if you are interning to qnames, e.g. <a> has two namespaces |
| 09:43 | <hsivonen> | yeah |
| 09:43 | <Hixie> | also you need to do attribute interning in a way that differs based on the resulting namespace of the tag |
| 09:44 | <othermaciej> | does svg have camelCase attributes? |
| 09:44 | <Hixie> | yes |
| 09:44 | <Hixie> | and hyphenated ones |
| 09:44 | <Hixie> | and namespaced ones |
| 09:44 | <Hixie> | and... |
| 09:44 | <Hixie> | hsivonen: i'm confused. what are you referring to as simon's proposal in this e-mail? hardcoding the html tags? |
| 09:45 | <hsivonen> | Hixie: blacklisting (some? all?) HTML tags |
| 09:45 | <Hixie> | that's what i thought |
| 09:45 | <Hixie> | that seems as bad as what i'm proposing |
| 09:45 | <Hixie> | if no worse |
| 09:46 | <hsivonen> | Hixie: ok. the point is that there is a proposed solution that addresses the problem cases your search turned up |
| 09:46 | <hsivonen> | so we are not in a situation of everything being fatally flawed |
| 09:46 | <Hixie> | specifically addressing five pages out of 5000 or however many it was isn't hard :-) |
| 09:47 | <Hixie> | the point is that we don't know exactly what we'll find |
| 09:47 | <hsivonen> | Hixie: no, they were magically addressed with proposals made before seeing the specific cases |
| 09:47 | <hsivonen> | I wasn't coming up with solutions as I went |
| 09:47 | <Hixie> | i disagree that they're all addressed, but i'll reply to your e-mail tomorrow with details |
| 09:48 | <hsivonen> | ok |
| 09:48 | <Hixie> | (e.g. i don't see how <math></p> is handled in your proposal) |
| 09:49 | <hsivonen> | Hixie: <p><math></p> is what the real case had and my proposal only changed the namespace of <math> in that case |
| 09:49 | <Hixie> | (also, your proposals that end up putting xhtml content in mathml don't work, because mathml renderers are supposed to flag an error in that case) |
| 09:50 | <hsivonen> | Hixie: Gecko doesn't |
| 09:50 | <Hixie> | gecko does in some cases, but not all |
| 09:50 | <hsivonen> | Gecko == MathML5 rendering :-) |
| 09:50 | <Hixie> | e.g. iirc <mfrac><mo/><mo/><mo/></mfrac> has an error message iirc |
| 09:50 | <Hixie> | too many iircs |
| 09:52 | <Hixie> | i guess hardcoding a list of html elments isn't necessarily so bad |
| 09:52 | <Hixie> | for svg |
| 09:52 | <Hixie> | though |
| 09:52 | <Hixie> | no |
| 09:52 | <Hixie> | even for svg it wouldn't work |
| 09:53 | <Hixie> | since they'd get hidden |
| 09:53 | <Hixie> | btu we could hardcode those element names to exit the <math> or <svg> scope |
| 09:53 | <Hixie> | that might work |
| 09:53 | <Hixie> | though then we'd have to have special handling for <math><image> which wouldn't be compatible with content mathml... |
| 09:53 | <Hixie> | hmmm |
| 09:54 | <Hixie> | so complicated |
| 09:54 | <Hixie> | gah |
| 09:54 | <hsivonen> | chances are that special-casing image to stay a MathML image won't break stuff |
| 09:54 | <Hixie> | you're far more willing to take chances than i am |
| 09:55 | <hsivonen> | btw, once you have an insertion mode for math, letting Content MathML pass through becomes mostly memory footprint |
| 09:55 | <Hixie> | i think there's a direct correlation between how many browsers one has shipped and how reluctant one is to make changes that might break random pages :-) |
| 09:56 | <hsivonen> | well, at least I have enough Evangelism product experience from b.m.o not to be totally reckless |
| 09:56 | <Hixie> | my main problem with content mathml isn't a parser issue (though adding 140 tag names certainly isn't my idea of a good plan), it's that including two copies of every equation is bad design, and that nobody uses content mathml anyway |
| 09:57 | <Hixie> | it's basically the same reason i'm reluctant to add much of aria, or rdfa |
| 09:57 | <othermaciej> | I've only shipped one so I'm totally prepared to change Safari to process all text/tml documents with the xhtml namespace declaration as strict XHTML2 |
| 09:57 | <Hixie> | it's all theory, unproved on the web |
| 09:57 | <othermaciej> | I've learned recently that Google Reader uses ARIA |
| 09:57 | <Hixie> | othermaciej: you've shipped more than one browser. you've shipped three in recent memory alone (safari 3, safari 3.1, and iphone safari) |
| 09:57 | <othermaciej> | well, sort of |
| 09:58 | <othermaciej> | Hixie: oh, you're counting by version |
| 09:58 | <Hixie> | google reader can have aria grafted onto it if you use firevox, right? |
| 09:58 | <hsivonen> | Hixie: in fact, in my evang days, I was against a web-breaking change you were for :-) |
| 09:58 | <Hixie> | othermaciej: how many you've shipped, right :-) |
| 09:58 | <Hixie> | hsivonen: :-) |
| 09:58 | <Hixie> | hsivonen: you're regressing! :-P |
| 09:59 | <othermaciej> | in that case, forget about the XHTML2 |
| 09:59 | <othermaciej> | anyway, Google Reader supposedly uses ARIA, but you have to follow an invisible offscreen link to get to the ARIA-enabled version |
| 09:59 | <othermaciej> | and even then it apparently only applies ARIA markup when it thinks the receiving browser knows ARIA |
| 09:59 | <othermaciej> | and even then it apparently only puts it on a handful of elements |
| 10:00 | <othermaciej> | still, it is a significant public web app using ARIA |
| 10:01 | <Hixie> | if you're going to include web apps whose aria support was added by the people writing, implementing, or evangelising the spec, i think you're not going to be doing yourself a good service in determining its popularity |
| 10:01 | <hsivonen> | othermaciej: why is that? bandwidth? |
| 10:01 | <othermaciej> | hsivonen: that's what T.V. Raman said, but I'm pretty puzzled why it requires both following a hidden link, *and* a UA check, to get the ARIA markup |
| 10:02 | <othermaciej> | you would think the former renders the latter moot as a bandwidth-saving measure |
| 10:02 | <Hixie> | hsivonen: hard coding the html elements in the svg mode is going to be a bitch, since we'd have to make the tokeniser not case-fold, then do a separate case-fold to check for known html elements |
| 10:03 | <hsivonen> | :-( |
| 10:03 | <Hixie> | hsivonen: also, the parser right now doesn't have every html tag name hardcoded, and it seems like if there's one language we'd want to keep open-ended in the html parser, it's html... |
| 10:03 | <Hixie> | thought admittedly, the forward-compat story of a hardcoded whitelist for mathml/svg isn't hot |
| 10:21 | <Hixie> | hsivonen: btw, your idea seems to require pretty big changes to the spec, much more than just adding a few insertion modes :-) |
| 10:22 | <Hixie> | hsivonen: (my idea fails to get the same end tag handling beahviour as you, but e.g. doesn't have to change both "in cell" and "in body" modes) |
| 10:22 | <jgraham> | Hixie: It's really not clear to me why the cargo-cult copy and paste objection applies to SVG and MathML triggers but doesn't apply to elements like <progress> or <datagrid> |
| 10:23 | <Hixie> | jgraham: it applies to those too, i just couldn't find a better solution for those |
| 10:25 | <jgraham> | Hixie: If it's an acceptable risk in those cases, it seems like an acceptable risk in the SVG+MathML case given the hardcoding tag names solutions seems to open us up to a world of pain in the future |
| 10:27 | <Hixie> | jgraham: <progress> and <datagrid> are much smaller parts of the spec and would be easier to fix if they did break in this way, so the risk is smaller. but the risk is still present, and if some workable alternate solution could be found, we'd want to use it. |
| 10:27 | <Hixie> | jgraham: in most of the proposals for math and svg, |
| 10:27 | <Hixie> | er |
| 10:27 | <Hixie> | jgraham: ...the triggers are already present |
| 10:28 | <Hixie> | jgraham: so it's not a cargo cult issue, but a real backcompat issue |
| 10:28 | <Hixie> | hm actually the idea i wrote up doesn't handle <td><math></body> correctly |
| 10:29 | <Hixie> | henri's handles <math><mrow><mi></mrow> by implying the </mi>... maybe that's better than mine, which tries to not support that kind of implication ata ll |
| 10:30 | <Hixie> | hm, handling <td><math>anything is going to be a huge pain however we do it |
| 10:30 | <jgraham> | Yeah, obviously the existing-compat. issue obviously has to be handled. However that seems much more tractable than the hypothetical future compat issue which I think breaks every solution with outherwise desirable properties |
| 10:30 | <webben> | re big apps using ARIA, note that there is currently ongoing work to integrate it into Yahoo! Mail: http://www.paciellogroup.com/blog/?p=45 |
| 10:31 | <Hixie> | jgraham: we can't just ignore the intractable problems :-) |
| 10:34 | <Hixie> | i might have to have a hierarchy of active insertion modes |
| 10:34 | <Hixie> | so that the math mode knows what insertion mode to toss unknown tokens to |
| 10:34 | <jgraham> | Hixie: Of course. But I'm not sure it's actually as significant a problem as you make out and, given it is already a problem in other parts of the spec, I don't think it should be a blocker here |
| 10:34 | <hsivonen> | webben: do you happen to know how popular screen readers convey CONTROLLER_FOR to the user? |
| 10:34 | <Hixie> | jgraham: i understand |
| 10:34 | <Hixie> | jgraham: but i disagree |
| 10:36 | <jgraham> | Hixie: The other problem is given it is a hypothetical future situation, I can't see what evidence would help decide the case |
| 10:37 | <hsivonen> | jgraham: I think the cargo cultist scenario here shouldn't be allowed to stop us |
| 10:37 | <webben> | hsivonen: Nope, sorry. I don't know much about the details of how MSAA roles are used. The person to ask would be Leventhal. Or alternately maybe look at http://svn.nvda-project.org/nvda/ |
| 10:38 | <hsivonen> | in particular, it is very unlikely for a cargo cultist to paste MathML or SVG on purpose, see that it does nothing and still continue |
| 10:38 | <webben> | (which is the only MSAA-using source code we can actually see) |
| 10:38 | <webben> | well, screenreader wise |
| 10:38 | <hsivonen> | only pasting <math> or <svg> start tag by accident seems like gaffe we shouldn't cater for |
| 10:39 | <hsivonen> | webben: thanks |
| 10:39 | <webben> | hsivonen: Note that it might well vary from app to app too. e.g. if Opera used CONTROLLER_FOR for their MSAA implementation, readers might need to interpret it differently to how it's used in IE and Moz. |
| 10:39 | <hsivonen> | webben: I think that aspect of screen readers is anti-competitive |
| 10:40 | <Hixie> | jgraham: i think there's ample evidence that what i describe happens, just look at the amount of mathml or xhtml or other xml crap in text/html documents |
| 10:40 | <webben> | hsivonen: It's not an aspect of screen readers. it's an aspect of MSAA (being unexpressive) and of /browsers/ doing things differently, generally with the best intentions as far as I can see. |
| 10:41 | <hsivonen> | Hixie: I think your argument works much better for "other XML crap" that is supposed to be kewl metadata (RDF) than for stuff that's supposed to render in a very distinct way |
| 10:42 | <webben> | hsivonen: That is to say, apps striving for interoperability with screen readers have to overload MSAA. |
| 10:42 | <jgraham> | Hixie: I havne't seem much evidence for "mathml crap" in text/html |
| 10:42 | <jgraham> | Most of the <math> tags seem to be randomly invented |
| 10:42 | <Hixie> | hsivonen: even before IE8 came out, people were putting IE8 mode switching synax on their sites, before even knowing what it would do |
| 10:43 | <Hixie> | jgraham: see one of my recent e-mails to public-html, i included stats |
| 10:43 | <hsivonen> | Hixie: that's still different from MathML and SVG subtrees |
| 10:44 | <hsivonen> | Hixie: but yeah, "you can deploy <XML vocabulary here> today!11!!1" is a really bad idea |
| 10:44 | <hsivonen> | that's how XHTML got poisoned |
| 10:44 | <Hixie> | hsivonen: indeed, xhtml is another pretty big example of this |
| 10:44 | <Hixie> | hsivonen: and an example that _did_ prevent browsers from being able to deploy the support in text/html |
| 10:45 | <hsivonen> | (and XHTML2 is repeating it with its alleged backwards compat advocacy) |
| 10:45 | <Hixie> | all of these lessons apply to us too |
| 10:45 | <Hixie> | with svg and mathml |
| 10:45 | <Hixie> | anyway |
| 10:45 | <Hixie> | i must sleep |
| 10:45 | <Hixie> | bbl |
| 10:45 | <Hixie> | nn |
| 10:45 | <hsivonen> | nn |
| 10:45 | <jgraham> | nn |
| 10:47 | <jgraham> | As a passing thought, would there be some way to use <object> and a magic mime type to get existing browsers to fall back to nothing |
| 10:47 | jgraham | has to go now, so can't think about the idea more fully |
| 10:48 | <jgraham> | (obviously overloading object even more is A Bad Thing, but there we go) |
| 10:49 | Lachy_ | wants to see an implementation of RFC 5242 |
| 10:50 | <mpt> | "even before IE8 came out" - did I miss something? ;-) |
| 11:45 | <hsivonen> | hmm. ARIA, ... http://news.slashdot.org/article.pl?sid=08/04/02/2242200 |
| 11:49 | <Lachy> | yeah, unfortunately, ARIA is almost as bad as the RIAA. |
| 11:54 | <hsivonen> | (in Finland, radio stations have to pay a fee to royalty collection societies in order to copy CDs to a hard disk-based jukebox) |
| 11:54 | <hsivonen> | It's insane and wrong. |
| 11:55 | <Lachy> | of course it is. copyright needs to reformed everywhere in the world. |
| 11:56 | <Lachy> | I wouldn't be surprised if many DJs just ignore the extra, unwarrented licence fee, since many would have already format shifted their libraries |
| 12:15 | shepazu | is tickled that hsivonen picked up the St.Vincent and the Grenadines joke (long standing on the #svg IRC channel) |
| 12:17 | <hsivonen> | shepazu: W3C graphics activity clearly has a conspiracy to appropriate names of island states like Papua New Guinea |
| 12:18 | <shepazu> | and the little-known state of Romania-Duetschland Feld |
| 12:20 | <shepazu> | not to mention Micronesia And The Higher Mountain Lands |
| 12:20 | <shepazu> | PNG's a very good one, though, nice work! |
| 12:26 | <shepazu> | hsivonen: have you outlined your SVG/MathML proposal on http://wiki.whatwg.org/wiki/Extensions ? |
| 12:39 | <Lachy> | does anyone recall the reason why irrelevant="" was initially chosen instead of hidden=""? |
| 12:40 | shepazu | suspects to avoid conflation with display:hidden |
| 12:41 | <shepazu> | or because it's a semantic judgment? that's the reason why it's hidden? |
| 12:41 | <annevk> | i think irrelevant is more specific than hidden |
| 12:41 | <annevk> | hidden can be used to hide anything, that's not the purpose of irrelevant |
| 12:42 | <Dashiva> | Hidden inputs are quite relevant, at least |
| 12:43 | shepazu | suggests "sekkrit" |
| 12:46 | <annevk> | but given that a lot of people miss the point of irrelevant... |
| 12:52 | <hsivonen> | shepazu: I haven't. Besides, now that Hixie seems to be OK with new insertion modes after all, I think it wouldn't be worthwhile for me to reoutline a proposal without insertion modes |
| 12:52 | <hsivonen> | shepazu: my initial gut reaction was that a couple of new insertion modes is the way to go anyway |
| 12:53 | <annevk> | I'm not sure I like the idea of having special handling of /> in the HTML parser after all |
| 12:54 | <hsivonen> | Lachy: as I understand it, Hixie considered 'hidden' presentational but 'irrelevant' looks semantic |
| 12:54 | <hsivonen> | annevk: easy use of existing SVG and MathML output requires it, so we have to bite the bullet and process it |
| 12:55 | <annevk> | irrelevant should not be used for rollover menus, aria-hidden is designed for that, amongst other things |
| 12:55 | <annevk> | they are fairly different |
| 12:55 | <annevk> | hsivonen, the problem is that it will be very confusing for authors that <div /> doens't do the same |
| 12:56 | <hsivonen> | annevk: text/html is tough |
| 12:56 | <annevk> | on the authoring side it's not that confusing so far |
| 12:57 | <annevk> | I think /> versus > being different on several elements would make it tough |
| 12:57 | <hsivonen> | annevk: I think we have to make it confusing here in order to make stuff work |
| 12:58 | <Lachy> | is the proposal to make /> behave like real XML for SVG and MathML elements? |
| 12:58 | <Lachy> | in text/html |
| 12:58 | <hsivonen> | agrh. Firefox 3b5 is annoyingly b0rked |
| 12:58 | <hsivonen> | loads fail randomly and often |
| 12:58 | <annevk> | Lachy, to make it pop the element from the stock, yes |
| 12:58 | <annevk> | stack, even |
| 13:00 | hsivonen | can't even get b.m.o to load |
| 13:25 | <hsivonen> | it would be great if Opera declassified the hard facts of the xmlns experiment |
| 13:27 | <annevk> | I did some time ago on IRC |
| 13:27 | <annevk> | the main problem was xmlns on HTML content |
| 13:28 | <hsivonen> | ah |
| 13:28 | <hsivonen> | that doesn't rule out Sam's suggestion, then |
| 13:29 | <annevk> | Probably not, did anyone argue that way? |
| 13:29 | <hsivonen> | not yet |
| 13:30 | <hsivonen> | btw, I can come up with a mechanism that would make it *possible* to defeat cargo cultists but which would also make things so annoying as to make the feature useless: |
| 13:31 | <hsivonen> | making authors provide a cryptographic hash of the concatenation of the URI of the page and the string "I am not a cargo cultist. I will not deploy markup features speculatively and proactively without testing in a browser that implements the new feature." |
| 13:35 | <annevk> | Though using xmlns="" seems dangerous nonetheless |
| 14:00 | <Philip`> | hsivonen: That won't work if the cargo-cultist in question does not understand English, and just copies-and-pastes it as an opaque string |
| 14:04 | <Dashiva> | Philip`: We'll extend the string to include translations |
| 14:04 | <Dashiva> | That way it's an automatic encoding checker too! |
| 14:04 | <Philip`> | A better solution is a global blacklist shared by all the browsers which lists sites that misuse various features and should be processed in a legacy compatibility mode |
| 14:05 | <hsivonen> | Philip`: it still stops an English-illiterate cargo cultist from pasting successfully |
| 14:05 | <hsivonen> | Philip`: without having to look up in some language what the magic hash operation is |
| 14:07 | <hsivonen> | of course, this approach would fail for two reasons: it would annoy non-cultists too much and it could be automated in PHP |
| 14:08 | <hsivonen> | <svg clue-token='<?php clue(); ?>'> |
| 14:10 | <annevk> | It also doesn't pass the not-silly test. As in, "Does this proposal sound silly? Yes!" |
| 14:14 | <Lachy> | Philip`, are you volunteering to create that extremely large blacklist :-) |
| 14:58 | <annevk> | http://www.markbaker.ca/blog/2008/02/10/media-type-centralization-is-a-feature-not-a-bug/ |
| 14:59 | <annevk> | That seems sort of applicable to markup vocabularies as well... |
| 15:01 | <hsivonen> | yeah, I'm inclined to consider distributed extensibility a bug. I want SVG and MathML, though. |
| 15:05 | <annevk> | Me too, I'm sort of convinced by the statement that math and graphics are important basic utilities |
| 15:07 | <hsivonen> | I wonder how much work it would be to write a non-caching HTTP proxy using Jetty and Commons HttpClient |
| 15:21 | <shepazu> | +1 to having a top-level global tracker view... I'm involved in many areas |
| 15:22 | <shepazu> | oops |
| 15:22 | <shepazu> | ww :D |
| 15:34 | <annevk> | shepazu, whatwg, w3c, all the same :p |
| 15:34 | <shepazu> | hahaha :) nice |
| 16:07 | <annevk> | hmm, the claims that Opera has special treatment for <script/> are bogus, fwiw |
| 16:08 | <annevk> | he should have tested what happens for <script> in the same scenario... |
| 16:10 | <annevk> | it's especially funny as he thinks he's setting the facts straight |
| 16:10 | annevk | is also easily amused |
| 16:23 | <annevk> | zcorpan, question, does Firefox 3 drop support for namespaced ARIA _everywhere_? |
| 16:23 | <annevk> | (I know we did) |
| 16:25 | <hsivonen> | annevk: http://groups.google.com/group/mozilla.dev.accessibility/browse_thread/thread/3354f74dba0bb9e0/37eb29f8c5a5a46e?lnk=gst&q=aria#37eb29f8c5a5a46e |
| 16:34 | <annevk> | k great |
| 16:35 | <annevk> | so they're just a useful fiction for the TAG |
| 16:44 | <hsivonen> | the example immediately before http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221/#s_rdfterminology is interesting |
| 16:44 | <hsivonen> | You might also like his |
| 16:44 | <hsivonen> | <span about="urn:ISBN:1596913614" instanceof="biblio:book"> |
| 16:44 | <hsivonen> | autobiography |
| 16:44 | <hsivonen> | </span>. |
| 16:45 | <hsivonen> | honestly, I can't imagine authors writing that |
| 16:47 | <annevk> | I wouldn't. I'm not even bothering with <abbr> anymore most of the time... |
| 16:48 | <annevk> | (And don't say I could autogenerate it, because if I can autogenerate it, the reader could as well...) |
| 16:48 | <annevk> | (And it would be far more effective for the reader to do it as it would affect more content.) |
| 16:53 | <hsivonen> | It's kinda sad that Creative Commons puts their effort into RDFa when they haven't solved the problem if getting random Flickr users to understand what legal implications licensing has--no matter how conveyed |
| 16:54 | <hsivonen> | It would also be super, if RDF could clarify what NonCommercial means |
| 16:54 | <annevk> | I would expect that not everyone in CC is devoted to the RDF stuff :) |
| 16:54 | <annevk> | As in, that's prolly the R&D department... no? |
| 16:55 | <Dashiva> | Is your site commercial if you have adwords? |
| 17:24 | <zcorpan> | the bart-logo.svg image would render correctly under hsivonen's proposal when parsed as text/html (although the rdf and inkscape cruft would be in the "wrong" namespace) |
| 17:25 | <zcorpan> | annevk: yes, they did, or so i was told |
| 18:04 | <annevk> | hmm, maybe http://lists.w3.org/Archives/Public/public-html/2008Apr/0051.html was a joke |
| 18:09 | <annevk> | gsnedders, could you elaborate on why <ext> is better? |
| 18:10 | <annevk> | (on the list, preferably) |
| 18:10 | <gsnedders> | annevk: it's mainly down to what I think will affect legacy content the least |
| 18:12 | <annevk> | having to use <ext> to use something as basic as graphics or math on the Web seems like a pain |
| 18:12 | <shepazu> | gsnedders: I am a little suspicious that you agree with me :) |
| 18:12 | <gsnedders> | shepazu: I agree with you? Oh no. I need to change my opinion now :) |
| 18:12 | <shepazu> | :D |
| 18:13 | <gsnedders> | (On a more serious note, it proves that I don't, as has been accused, blindingly follow what Hixie says) |
| 18:13 | <shepazu> | annevk: it's one element... it's essentially like a div, and that's as common as mosquitoes in Louisiana |
| 18:14 | <shepazu> | gsnedders: did Hixie tell you to say that? ;P |
| 18:14 | <gsnedders> | shepazu: So I can take that as mosquitoes in Louisiana are as common as div elements, seeming I don't know how common they are? |
| 18:14 | <gsnedders> | shepazu: Yes ;'( |
| 18:14 | <annevk> | Both math and graphics already have a container. I don't really see the need to have two. Also, I don't like <div> |
| 18:14 | <shepazu> | yes, by the transitive property of elements and insects |
| 18:15 | <shepazu> | annevk: but they don't have a fallback mechanism |
| 18:15 | <gsnedders> | annevk: But what about things apart from maths and graphics? |
| 18:15 | <shepazu> | gsnedders: louisiana is famously hot and swampy |
| 18:15 | <shepazu> | (and, after Katrina, under water) |
| 18:15 | <gsnedders> | shepazu: Not famous enough for me to know :) |
| 18:16 | <shepazu> | ants at a picnic, then? |
| 18:16 | <annevk> | shepazu, I don't think we need fallback works that well |
| 18:17 | <annevk> | oops |
| 18:17 | <annevk> | I don't think fallback works that well |
| 18:17 | <shepazu> | annevk: I loaf cow pickle seems |
| 18:17 | <shepazu> | annevk: how does it not work well? |
| 18:18 | <annevk> | Authors will simply use whatever the dominant UA supports with perhaps some SEO spam/accessibility aid in alt="". |
| 18:18 | <annevk> | So if the dominant UA supports SVG there's no incentive to put fallback stuff for down-level UAs. This becomes even more true when all UAs support SVG. |
| 18:18 | <shepazu> | gsnedders: anyone who agrees with Hixie in public more than they disagree with him will be accused of being part of a conspiracy, so don't let that get to you |
| 18:19 | <gsnedders> | shepazu: I don't :P |
| 18:19 | <annevk> | (Having fallback might also give less incentive for UAs to support something.) |
| 18:19 | <gsnedders> | shepazu: I just muck around with the fact I'm accused :) |
| 18:19 | <gsnedders> | shepazu: (though maybe not the best thing to do in the atmosphere :() |
| 18:19 | <shepazu> | gsnedders: then quit yer bellyaching |
| 18:19 | <shepazu> | :) |
| 18:19 | <gsnedders> | shepazu: What do you expect of someone my age!? |
| 18:20 | <shepazu> | sitting around all night playing GTA? |
| 18:20 | <shepazu> | pimples? |
| 18:20 | <gsnedders> | But I'm not 18! I can't play GTA! |
| 18:20 | <shepazu> | whaaaa? |
| 18:20 | <shepazu> | for real? |
| 18:20 | <shepazu> | you have to be 18 to play GTA? |
| 18:20 | <gsnedders> | shepazu: under British law, yeah |
| 18:21 | <shepazu> | whoah. |
| 18:21 | <Dashiva> | gsnedders, you liar. You said you were 43! |
| 18:21 | <gsnedders> | Dashiva: No, 42. |
| 18:21 | <Dashiva> | oh |
| 18:21 | <shepazu> | I thought you guys beat the nazis in WWII |
| 18:21 | <gsnedders> | Dashiva: Remember the disclaimer of everything I say on April 1st being bullshit :) |
| 18:21 | <Dashiva> | But I thought that disclaimer was bullshit ;) |
| 18:21 | <gsnedders> | shepazu: (admittedly, I'm getting GTA4 for my 16th birthday this month) |
| 18:22 | <shepazu> | annevk: those don't seem like reasons *not* to have a fallback, since we can't rely on a UA supporting SVG and MathML (especially retroactively) |
| 18:23 | <gsnedders> | shepazu: Though legally it is a min. age to buy it, not to own it |
| 18:23 | <shepazu> | gsnedders: so, basically, I was right? |
| 18:23 | <gsnedders> | shepazu: I've been playing Crackdown recently, but close enough :) |
| 18:23 | <gsnedders> | http://en.wikipedia.org/wiki/BBFC FWIW |
| 18:24 | <annevk> | shepazu, you will have transition issues nonetheless, given <foreignObject> and <semantics> and all |
| 18:24 | <Philip`> | I got my parents to buy GTA1 for me and fortunately they didn't notice it said '18' on it |
| 18:24 | <shepazu> | annevk: yup, some transition issues seem inevitable, but we can minimize their impact |
| 18:25 | <gsnedders> | Philip`: heh. My parents know damned well what it's like… At least partially. |
| 18:26 | <Philip`> | Now you can just borrow a credit card and buy it on Steam and there won't even be a box to raise suspicions |
| 18:26 | <gsnedders> | Philip`: consoles ftw |
| 18:27 | <annevk> | shepazu, I don't think there's much impact to begin with |
| 18:27 | <gsnedders> | Philip`: Oh, and I'll probably give you a hard challenge with an XHTML site I'll be working on late this year. |
| 18:27 | <shepazu> | annevk: I think there are definitely impact issues on the larger Web environment |
| 18:29 | shepazu | really wants to play Portal... I played several levels, and it was fun |
| 18:29 | <gsnedders> | brb (then I go work on http-parsing) |
| 18:29 | <Philip`> | shepazu: I would recommend wanting to play Portal :-) |
| 18:30 | <shepazu> | I played it at a friend's house... I need to find time to get over there again to finish it |
| 18:34 | <Philip`> | It's only a few hours long, so it should be easier to find time than for most other games |
| 18:39 | <gsnedders> | shepazu: I guess you could also take GTA as going against what a minority of emos do: self-harm; just digitally doing it :P |
| 18:54 | <gsnedders> | any suggestions for someone who is writing a website in Python for the first time are welcome (*nudge*) |
| 18:55 | <jwalden> | "good job on not using Perl!" |
| 18:56 | <gsnedders> | :D |
| 18:59 | gsnedders | wonders whether to do everything through CGI himself |
| 19:00 | <Dashiva> | "Hissssss" |
| 19:41 | <Hixie> | hsivonen: my objection to insertion modes was to insertion modes that didn't immediately fallback to the previous one on error, but with some sort of hardcoded list (white or black, i'm still working on the implications of that) i think it makes sense |
| 19:49 | <hsivonen> | Hixie: ok |
| 19:49 | <BenMillard> | hixie, is it OK if I use your IRC messages about my research to show potential sponsors that my work is of use to HTML5's development? specifically, the quoted block here: http://projectcerbera.com/blog/2008/03#day25 |
| 19:52 | <annevk> | BenMillard, fwiw, you're not subscribed to public-pfwg-comments |
| 19:53 | <annevk> | It does not seem you can subscribe to that list without permission |
| 19:53 | <BenMillard> | annevk, thanks I was starting to suspect it hadn't worked |
| 19:53 | <annevk> | I've no idea why |
| 19:54 | <annevk> | You should be able to ask Alfred.S.Gilman⊙Io and cooper⊙wo for the reasons. They are the list maintainers |
| 19:54 | <BenMillard> | annevk, ok, I'll do that now |
| 19:56 | <annevk> | It's also slightly weird that the accessibility stuff is Member-only |
| 19:58 | shepazu | agrees that accessibility stuff, perhaps especially, should be open |
| 19:58 | <BenMillard> | I'll ask if they've considered making their process as open as e.g. HTMLWG's |
| 19:58 | <shepazu> | I wonder if anyone has talked to them about rechartering to be moreopen |
| 19:59 | <BenMillard> | shepazu, great minds think alike :P |
| 19:59 | <shepazu> | no, mediocre minds think alike, great minds think singularly :D |
| 19:59 | <BenMillard> | and fools seldom differ :( |
| 19:59 | <shepazu> | sadly, it's clear where that puts me :( |
| 20:00 | <csarven> | BenMillard re: markup for dialogue. <blockquote><table> because <blockquote> supposed to represent the whole conversation? |
| 20:04 | <BenMillard> | csarven, <blockquote> because it's taken from another source (and IRC log) |
| 20:04 | <BenMillard> | s/and/an |
| 20:06 | <csarven> | "taken from another source" suggests that the context is important |
| 20:07 | <csarven> | If you were to markup an interview article would it still be a single <blockquote> ? (I suppose the conversation is "from some other event") |
| 20:08 | <BenMillard> | csarven, the link "discussed my research on #whatwg" links to where it came from. I could add that to the cite attribute on the <blockquote> as well, though |
| 20:08 | <Hixie> | BenMillard: sure |
| 20:08 | <BenMillard> | hixie, thanks |
| 20:09 | <Hixie> | np |
| 20:12 | <BenMillard> | csarven, cite attribute added. using <blockquote> that way for the transcript of a spoken or e-mailed interview makes sense to me |
| 20:13 | <BenMillard> | but if I were blogging a fictitious dialogue onto a web page, <blockquote> wouldn't seem right to me as the dialogue has not come from another source: it's first appearence is on that page |
| 20:14 | <csarven> | Say the dialogue is from an IM conversation, similar to IRC that it occured elsewhere from 'this' page. |
| 20:15 | <csarven> | But I see your point about the "fictitious dialogue" |
| 20:16 | <BenMillard> | good grief...did 2 people just *agree* about how to use an HTML element?! |
| 20:17 | <Lachy> | I don't see any problem with using blockquote to mark up a ficticious dialog |
| 20:18 | <Lachy> | if in the context of the page, it's clear that it's not a real dialogue, what's the problem? |
| 20:18 | <Dashiva> | BenMillard: You mean <em>agree</em> |
| 20:20 | <csarven> | Yes, I think <blockquote> is fine for a ficticious dialog too |
| 20:21 | annevk | thought <dialog> was for dialogues |
| 20:21 | <csarven> | It is an indication that seperates a quoted text from the rest |
| 20:21 | <Hixie> | these are going to be a problem: |
| 20:21 | <annevk> | though <dialog> is a poor name for a spec that does both documents and applications |
| 20:21 | <Hixie> | <table><caption><math><mrow><mtext><svg><circle></mrow> |
| 20:21 | <Hixie> | <table><caption><math><mtext><svg><circle><caption> |
| 20:22 | <csarven> | BenMillard I agree with the single use of <blockquote> there that the whole dialogue is some quoted text |
| 20:23 | <csarven> | As opposed to each single quoted line having its own <blockquote> |
| 20:24 | <csarven> | The latter case will be accurate if the dialogue is not continuous (using excerpts) |
| 20:28 | <annevk> | Hixie, why can't </mrow> imply closing tags? |
| 20:28 | <csarven> | As far as <blockquote><table>, <table> is a bit more like <ul> or <dl> as opposed to <ol> that there is no "order" to the conversation |
| 20:29 | <annevk> | Hixie, why can't <caption> do the same? |
| 20:29 | <Hixie> | anne: consider <svg><desc><table><caption><svg><foreignObject><math><mtext></foreignobject></desc> |
| 20:30 | <Hixie> | annevk: we want the </foreignobject> to close the <foreignObject>, which means it somehow has to be case mapped at some point |
| 20:30 | <Hixie> | annevk: we want the </desc> _not_ to close the <desc> |
| 20:30 | <Hixie> | i'm just not sure how to implement all that in the spec |
| 20:31 | <BenMillard> | Lachy, allowing <blockquote> to contain content which was not taken from another source basically turns it into <div>, afaict |
| 20:31 | <annevk> | do case mapping cross language :) |
| 20:31 | <annevk> | euh |
| 20:31 | <annevk> | textArea vs textarea... hmm |
| 20:32 | <Hixie> | annevk: we don't want to do case mapping cross-language. e.g. <html><foreignObject> should stay lowercase. |
| 20:32 | <BenMillard> | csarven, source order is significant to meaning. who goes around randomly re-arranging web content whilst leaving the contents of <ol> alone? :) |
| 20:32 | <annevk> | Hixie, well, you can do the case mapping inside svg/math scopes only presumably |
| 20:33 | <annevk> | Hixie, or you can decide that </foreignobject> does not close <math> and <mtext> |
| 20:33 | <Hixie> | annevk: consider <svg><desc><SPAN></DESC> |
| 20:33 | <Hixie> | the </foreignobject> closes <math> and <mtext> today |
| 20:33 | <Hixie> | so if we don't hardcode element names, it has to continue doing so for minimal risk |
| 20:34 | <Hixie> | if we hardcoded the svg and mathml element names, that'd be different |
| 20:34 | <Hixie> | because then anything else would just close the whole tree |
| 20:35 | <csarven> | BenMillard Fair! Then I would suggest something like this (a minor extension) <blockquote><table><tr> <th title="John Smith">JS</th> <td><p></p> <p></p></td> |
| 20:35 | <annevk> | Hixie, hmm, true |
| 20:36 | <annevk> | I wonder how much damage could be done if we permit ourselves some freedom |
| 20:37 | <BenMillard> | csarven, that looks OK but <th><abbr title="John Smith>JS</abbr> seems slightly more accurate |
| 20:37 | <BenMillard> | s/Smith>/Smith"> |
| 20:38 | <annevk> | <th abbr="John Smith"> |
| 20:38 | <annevk> | oh wait, that's not in HTML5! |
| 20:38 | <BenMillard> | annevk, HTML says abbr contains the short form, not the long form |
| 20:38 | <annevk> | and might be incorrect usage even |
| 20:38 | <annevk> | ah right, I always get that backwards |
| 20:38 | <BenMillard> | HTML4, I mean |
| 20:39 | <BenMillard> | but you could do <th abbr=JS>John Smith</th> and UAs could substitute the content with the abbr if the column go too narrow...maybe |
| 20:40 | <BenMillard> | annevk, I think <dialog> is unnecessary as existing elements can (and are) added together to handle the use cases. but I hope to research authoring patterns for dialogue on the web, so maybe I'll find a new element is required for sane markup |
| 20:44 | <csarven> | BenMillard You are right, more accurate |
| 20:53 | <BenMillard> | annevk, sent mail to PFWG. will blog it now so there's a public copy |
| 20:53 | <BenMillard> | well, to the chairs of PFWG you mentioned |
| 20:55 | <annevk> | you should cc www-archive⊙wo going forward presumably |
| 20:55 | <annevk> | so everyone involved knows the e-mail is public |
| 20:55 | <BenMillard> | d'oh, that would have been a much better idea |
| 20:55 | <BenMillard> | well, I'll only make their replies public if they say it's OK |
| 20:56 | <Hixie> | <html><em><button><math><mtext><b>xxx</em> |
| 20:56 | <Hixie> | vs |
| 20:56 | <Hixie> | <html><em><button><math><mtext><b>xxx</b> |
| 20:56 | <Hixie> | vs |
| 20:56 | <Hixie> | <html><em><button><math><mrow><mtext><b>xxx</mrow> |
| 20:56 | <Hixie> | ...is a pain |
| 20:57 | <annevk> | the last one renders slightly weird in Opera |
| 20:58 | <annevk> | actually, all do |
| 20:58 | <annevk> | Maybe you're thinking of more illogical cases than authors because you can :p |
| 21:00 | <Philip`> | Authors don't need to think of illogical cases, it just comes naturally to them :-) |
| 21:01 | <Hixie> | how the hell do i handle this case |
| 21:01 | <annevk> | the nested scope thing does not work? |
| 21:02 | <annevk> | if inside <math> put it in the math namespace unless it's an HTML element, etc. |
| 21:02 | <annevk> | or unless it's </foreignobject> |
| 21:04 | <Hixie> | the problem is not inside <math> |
| 21:04 | <Hixie> | the problem is inside <mtext>, <desc>, <foreignobject>, etc |
| 21:04 | <Hixie> | where we don't want to bail out |
| 21:07 | <csarven> | BenMillard Do you think there is an issue with <blockquote><ol><li><abbr title="John Smith">JS</abbr><p></p></li> .. </ol></blockquote> ? |
| 21:09 | <annevk> | Hixie, I'm not sure I understand that and the wiki page didn't help |
| 21:11 | <Hixie> | ok consider this: <b><math><mtext><i></b> |
| 21:11 | <BenMillard> | csarven, that seems OK to me |
| 21:11 | <Hixie> | annevk: now, when you get to the <mtext>, you switch to a mode that is aware of namespaces but that allows html to be embedded, right? |
| 21:11 | <Hixie> | annevk: so you see the <i>, and handle it as "in body" |
| 21:12 | <Hixie> | annevk: now what do you do when you see the </b>? |
| 21:12 | <Hixie> | annevk: if you just treat it as "in body", then you won't switch the insertion mode correct (and the stack will be back to html,body) |
| 21:12 | <Hixie> | annevk: if you do the popping yourself, you fail to do the AAA which you need to do |
| 21:12 | <Hixie> | annevk: so what do you do? |
| 21:13 | <annevk> | if you treat it as "in body" eventually some closing <mtext> will be generated, no? |
| 21:14 | <annevk> | can't you have something "special" there? |
| 21:15 | <Hixie> | annevk: as far as i recall, the AAA doesn't generate implied end tags |
| 21:15 | <Hixie> | it just pops the tags |
| 21:16 | <annevk> | aah, that could be true |
| 21:16 | <Hixie> | yeah: pop all the nodes from the bottom of the stack of open elements, from the current node up to and including the formatting element |
| 21:17 | <annevk> | you could reset the insertion mode after such things |
| 21:17 | <annevk> | (popping) |
| 21:17 | <annevk> | ideally with a comment that indicates why it's there |
| 21:20 | <annevk> | Hixie, or we decide it is not needed and have slightly saner HTML parsing inside math and graphics |
| 21:20 | <annevk> | (that does seem a bit icky) |
| 21:20 | <Hixie> | imho we can't do that |
| 21:21 | <Hixie> | resetting is expensive |
| 21:21 | <Hixie> | i'd rather not reset after every end tag in a namespaced block |
| 21:21 | <Hixie> | <table><caption><math><mrow><mtext><svg><circle></svg> |
| 21:21 | <Hixie> | is also annoying |
| 21:22 | <Hixie> | <table> - in table. <caption> - in caption>. <math> - in namespace. <mtext> - in namespace content. <svg> - in namespace. </svg> - well now |
| 21:22 | <Hixie> | we have to realise that we just _popped_ from namespaced to namespaced _content_. |
| 21:24 | <annevk> | hmm, jgraham and I had some issues sorting out nested namespaced content too |
| 21:26 | <zcorpan_> | perhaps we don't need to list *all* html tag names in <math> scope |
| 21:26 | <zcorpan_> | just figure out what people put in there today |
| 21:26 | <zcorpan_> | i've seen font, sub, sup |
| 21:27 | <hsivonen> | Hixie: I'd like <svg> to work where MathML allows <semantics> |
| 21:27 | <Hixie> | i'd like to kill <semantics> altogether |
| 21:27 | <Hixie> | :-) |
| 21:27 | <annevk> | hsivonen, do we really need to require <semantics>? |
| 21:27 | <annevk> | +1 to that plan |
| 21:27 | <annevk> | useless containers better just be removed |
| 21:27 | <hsivonen> | annevk: I said I want <svg> to work where MathML allows <semantics> :-) |
| 21:28 | <Hixie> | what's the use case? |
| 21:28 | <hsivonen> | Hixie: I need to look up the name of the tableaux |
| 21:29 | <hsivonen> | Hixie: Young Tableaux they seem to be called |
| 21:29 | <hsivonen> | Hixie: use case from Jacques Distler's blog as usual :-) |
| 21:30 | <Hixie> | i don't get it |
| 21:30 | <Hixie> | what do you want to have happen? |
| 21:30 | <hsivonen> | Hixie: see http://golem.ph.utexas.edu/~distler/blog/archives/001475.html in Firefox 3 |
| 21:31 | <hsivonen> | Hixie: I want to get a DOM with an SVG subtree that starts inside a MathML tree |
| 21:31 | <Hixie> | i've looked at that page many times |
| 21:31 | <Hixie> | i don't understand what <semantics> has to do with anything |
| 21:31 | <Hixie> | sure |
| 21:31 | <Hixie> | i agree with that |
| 21:31 | <Hixie> | but why in <Semantics>? |
| 21:31 | <Hixie> | surely it belongs better in <mtext> or <mi> or some such |
| 21:31 | <Hixie> | that's what i've been speccing so far |
| 21:31 | <annevk> | hsivonen argues he wants <svg> where MathML allows <semantics> |
| 21:31 | <Hixie> | i thought you were arguing for that too |
| 21:31 | annevk | misunderstood |
| 21:31 | <hsivonen> | Hixie: I meant I want <svg> to work in place of <semantics> where MathML now allows <semantics> |
| 21:32 | <hsivonen> | like here: http://hsivonen.iki.fi/test/svg-in-math.xhtml |
| 21:33 | <Hixie> | i don't think it makes sense in the spirit of mathml to have <svg> as a sibling of <mo>, but i'd agree that <math><mtext><svg/></mtext><mo>+</mo>... would make sense |
| 21:33 | <Hixie> | or <mi>, or <mn>, depending on what you're doing |
| 21:36 | <hsivonen> | still, I'm amused that a presentational markup language is the #1 use case for <semantics> in valid browser-targeted MathML |
| 21:36 | <annevk> | Hixie, is <mtext> really necessary? |
| 21:36 | <annevk> | oh well, no need to argue details now I suppose |
| 21:36 | <Hixie> | i'm amused that we're talking about adding the presentational version of mathml, and the exclusively presentational svg, to html. |
| 21:37 | <Hixie> | woot, i think i got it down to one additional insertion mode |
| 21:37 | <Hixie> | nstead of 4 |
| 21:37 | <hsivonen> | Hixie: but semantics aren't the end goal! :-) |
| 21:37 | <Hixie> | indeed |
| 21:37 | <annevk> | Hixie, that doesn't have to be a simplification :) |
| 21:37 | <Hixie> | turns out it is :-) |
| 21:39 | <gsnedders> | who needs no stinkin' semantics? |
| 21:39 | <Hixie> | http://wiki.whatwg.org/wiki/New_Vocabularies_Solution |
| 21:40 | <Hixie> | comments? |
| 21:40 | <zcorpan_> | i wonder if we can add support for cdata blocks everywhere |
| 21:40 | <zcorpan_> | well, opera does |
| 21:40 | <csarven> | BenMillard I think <ol><li><abbr><blockquote><p> is still slightly better |
| 21:41 | <zcorpan_> | it hasn't caused us trouble so far afaik |
| 21:41 | <annevk> | Opera doesn't do CDATA properly has been pointed out several times |
| 21:41 | <zcorpan_> | it still hasn't caused us trouble |
| 21:41 | <annevk> | it has, I believe |
| 21:41 | <zcorpan_> | oh? |
| 21:41 | <annevk> | MSDN uses it to hide some stuff |
| 21:42 | <zcorpan_> | interesting |
| 21:42 | <Hixie> | still need to work out exactly what "(html elements)" expands to |
| 21:42 | <annevk> | Hixie, looking |
| 21:43 | <annevk> | Hixie, oh, CDATA in just one mode? why that? I rather have it either on always or off always |
| 21:43 | <BenMillard> | csarven, that makes sense for some cases, too |
| 21:43 | <Hixie> | annevk: didn't you just say it would break msdn? |
| 21:44 | <annevk> | Hixie, 'φ works differently when in "in math" or "in math content".' doesn't work anymore |
| 21:44 | <annevk> | Hixie, so always off then... |
| 21:44 | <csarven> | The slight problem with having a single <blockquote> is that it is encapsulating the authors too and authors is not part of the quoted text |
| 21:44 | <Hixie> | annevk: that would break much existing svg content, as i understand it |
| 21:44 | <csarven> | <ol> is good because it indicates a chronological order at some level |
| 21:44 | <hsivonen> | Hixie: treat as if in the secondary mode seems no fun |
| 21:45 | <hsivonen> | Hixie: it probably leads to "in namespace" becoming a flag instead of a mode implementation-wise |
| 21:45 | <annevk> | Hixie, the <math/> case seems easier to handle if you handle the / before switching modes |
| 21:45 | <Hixie> | hsivonen: the secondary mode is only ever one of in caption, in cell, in table, or in body; you have to be able to handle treating as three of the four of those already |
| 21:46 | <Hixie> | annevk: yeah i haven't optimised the way it's written yet |
| 21:47 | <hsivonen> | Hixie: for those, I have carefully arranged switch fallthru |
| 21:47 | <zcorpan_> | cdata sections in svg is needed if svg <script> is pcdata |
| 21:47 | <zcorpan_> | supporting cdata sections is also a way to hide text in svg from legacy browsers |
| 21:47 | <hsivonen> | Hixie: I don't understand the formulation of the crucial bit |
| 21:48 | <annevk> | do we really want <svg:script> and <html:script> to be parsed differently? :( |
| 21:48 | <Hixie> | hsivonen: really? i couldn't work out how to make that work in practice, there was a tree, not a straight hiearchy |
| 21:48 | <Hixie> | hsivonen: switch fallback, i meant |
| 21:48 | <Hixie> | annevk: "we" might not :-) but i think we have to to handle svg from editors |
| 21:48 | <hsivonen> | Hixie: "# start tag if current node is <foreignobject>, <desc>, <title> in svg " "if the insertion mode is still "in namespace"" I don't understand how those steps work |
| 21:48 | <Hixie> | hsivonen: which part? |
| 21:49 | <zcorpan_> | annevk: dunno, but certainly <textArea> can contain elements |
| 21:49 | <Philip`> | I see CDATA on 14 out of 300 SVG images from Wikipedia |
| 21:49 | <hsivonen> | Hixie: there's a place of two where I have to shield an intermediate case block against a particular tag name, yeah |
| 21:49 | <BenMillard> | csarven, cases where the authors were not part of the quoted text are where I agree with your avoidance of an all-inclusive <blockquote> |
| 21:50 | <hsivonen> | Philip`: CDATA is mainly for Sam's fallback trick |
| 21:50 | <hsivonen> | Hixie: oooh!!! |
| 21:50 | <Hixie> | hsivonen: consider <span><math></span>, or <table><caption><math><mtext><aoptoin> |
| 21:50 | <Hixie> | er, caption |
| 21:50 | <hsivonen> | Hixie: I read it as if start tag is one of ... |
| 21:50 | <Hixie> | not aoptoin, whatever that is |
| 21:50 | <csarven> | BenMillard Which cases are there for dialougs without authors? |
| 21:50 | <virtuelv> | heh |
| 21:50 | <hsivonen> | instead of if the *current* node is ... |
| 21:50 | <virtuelv> | http://www.dehp.net/dars.htm |
| 21:50 | <Hixie> | hsivonen: ah, yeah, i'll need to make sure it's very clear in the spec version |
| 21:50 | <Philip`> | http://upload.wikimedia.org/wikipedia/en/f/fc/Tiger_Mascot.svg - a lovely use of CDATA there |
| 21:50 | <virtuelv> | look at the source |
| 21:51 | <Hixie> | zcorpan_: i have every intention of not supporting <textArea> |
| 21:51 | <Hixie> | zcorpan_: i'm considering not supporting <font>, either, but i'm not sure about that one |
| 21:51 | <Hixie> | need to study it |
| 21:51 | <Hixie> | as in, do a study |
| 21:51 | <BenMillard> | csarven, IRC logs, IM chats, quoted play scripts and so forth would include authors amogst the quoted text (as well as stage directions, join/leave messages, etc) |
| 21:52 | <hsivonen> | Hixie: "start tag if current node is <mi>, <mo>, <mn>, <ms>, <mtext> in mathml " not putting annotation-xml would be nice |
| 21:52 | <hsivonen> | doh |
| 21:52 | <hsivonen> | edit error |
| 21:52 | <hsivonen> | s/not// |
| 21:52 | <csarven> | BenMillard I don't understand. Why would the quoted text include the authors? |
| 21:53 | <Hixie> | hsivonen: really? i would have thought we'd specifically _not_ want to switch to html mode in <annotation-xml> |
| 21:53 | <annevk> | hsivonen, why would annotation-xml descendents be treated in secondary mode? |
| 21:53 | <annevk> | that would cause the much loved "content mathml" to be in the wrong namespace |
| 21:53 | <Philip`> | 4 of 300 Wikipedia SVG images use <font> |
| 21:54 | <Hixie> | Philip`: wow, which ones? |
| 21:54 | <hsivonen> | Hixie: I think we want to allow <svg> to become SVG there |
| 21:54 | <Philip`> | s/4/5/ |
| 21:54 | <hsivonen> | Hixie: I'm not sure I care enough about bikeshedding HTML and OpenMath |
| 21:54 | <Philip`> | Hixie: Lindos5.svg Log.svg Nilt-Political_Attitudes-NIRELAND-2006.svg PersCorpINtax_wi_5.svg Telecom.svg |
| 21:54 | <BenMillard> | csarven, quoting an IRC log, as we covered earlier, includes authors in the text: http://krijnhoetmer.nl/irc-logs/whatwg/20080328#l-342 |
| 21:55 | <Hixie> | hsivonen: reload |
| 21:55 | <hsivonen> | Hixie: although I do sympathize if math wg members want to tweak annotation-xml behavior |
| 21:55 | <hsivonen> | Hixie: thanks |
| 21:56 | <Hixie> | Philip`: holy jesus, that first one really has an entire fucking font in there |
| 21:56 | <Hixie> | that's insane |
| 21:56 | <Hixie> | i wonder how common that is |
| 21:56 | <Hixie> | that has to be the least efficient encoding of a font, ever |
| 21:56 | <hsivonen> | what should I prefix to load the SVG file Philip` mentioned? |
| 21:56 | <annevk> | soon it will be common through @font-face { src:url(data:...) } :D |
| 21:57 | <Hixie> | hsivonen: google for it |
| 21:57 | <hsivonen> | works |
| 21:57 | <hsivonen> | thanks |
| 21:57 | <Hixie> | annevk: oh wow that'd be even worse. Take a TTF font, convert to SVG, embed in a data: URL in CSS... |
| 21:58 | <hsivonen> | http://upload.wikimedia.org/wikipedia/en/b/b5/Lindos5.svg doesn't look right in Safari |
| 21:58 | <annevk> | hehehe |
| 21:58 | <hsivonen> | bah. ns missing |
| 21:58 | <Hixie> | yeah it's not really svg |
| 21:58 | <annevk> | btw, if annotation-xml is expected to contain a <math> container in case of alternative math maybe forwarding it to secondary mode for all elements isn't too bad |
| 21:58 | <csarven> | BenMillard Fair. Then we can agree on multiple ways of marking up dialogues/conversations etc.. :) |
| 21:59 | <Hixie> | screw φ, we'll just let it break |
| 21:59 | <Hixie> | annevk: is it? |
| 21:59 | <hsivonen> | annevk: forwarding to secondary mode would work for SVG, MathML and HTML |
| 21:59 | <annevk> | maybe we can have &mphi; |
| 21:59 | <hsivonen> | annevk: OpenMath would be the problem |
| 22:00 | <hsivonen> | annevk: and per David Carlisle on the list, not a common problem |
| 22:00 | <annevk> | hsivonen, I don't actually care about OpenMath or <annotation-xml> :) |
| 22:00 | <annevk> | I was just thinking that special casing it for <svg> might not make sense |
| 22:00 | <Hixie> | you know, with the caveat that we still have to hardcode all the html elements, we could just support xmlns="" in the final case on http://wiki.whatwg.org/wiki/New_Vocabularies_Solution |
| 22:00 | <Hixie> | i wonder how much that would break |
| 22:00 | <Hixie> | i guess it'd be pointless since you could only enter there through svg and mathml |
| 22:00 | <Hixie> | oh well |
| 22:01 | <hsivonen> | I guess I really have to write the proxy once I've got this stuff in the parser impl |
| 22:01 | <Hixie> | hsivonen: <annotation-xml> itself isn't common |
| 22:01 | <Hixie> | hsivonen: and i really wish i could just not support it |
| 22:01 | <Hixie> | along with <Semantics> and all of content mathml |
| 22:01 | <annevk> | you could have elements with a ns="" attribute... |
| 22:01 | <annevk> | but it'd be slightly ugly, etc. |
| 22:01 | <hsivonen> | annevk: wouldn't work for RDF copy-paste |
| 22:02 | <hsivonen> | Hixie: you haven't covered RDF in SVG <meta> |
| 22:02 | hsivonen | hides |
| 22:02 | <Hixie> | hsivonen: shocking |
| 22:02 | <Hixie> | hsivonen: whatever shall we do |
| 22:03 | <annevk> | is it <meta> or <metadata> ? |
| 22:03 | <hsivonen> | annevk: can't remember |
| 22:03 | <hsivonen> | Hixie: xlink still not covered |
| 22:03 | <Hixie> | hsivonen: it'll be part of "if namespace is svg, apply case fixups" |
| 22:03 | <hsivonen> | ok |
| 22:04 | <Hixie> | i still don't like hardcoding the html tags instead of the mathml and svg tags |
| 22:04 | <Hixie> | i'm not at all sure i can come up with an exhaustive list for html elements |
| 22:05 | <zcorpan_> | hmm. if we don't want to hardcode tag names, how about only entering math scope if xmlns=... is also present? |
| 22:05 | <hsivonen> | Hixie: one would think that mighty Google would know |
| 22:06 | <Hixie> | zcorpan_: the problem is that if we don't have a way to bail out, then pages with minor syntax errors can get stuck in the wrong mode |
| 22:07 | <zcorpan_> | Hixie: true |
| 22:07 | <Hixie> | hsivonen: how so? |
| 22:07 | <hsivonen> | Hixie: from your earlier element frequency research |
| 22:07 | <Hixie> | hsivonen: that includes thousands of completely bogus elements |
| 22:07 | <Hixie> | hsivonen: and misses others that may or may not be important, e.g. <keygen> |
| 22:08 | <zcorpan_> | we want html tags in <math> that do something -- have some non-default presentation or is <script> or some such |
| 22:08 | <Hixie> | i should do a study of what elements one finds inside <math> and <svg> elements today that aren't valid in mathml or svg |
| 22:10 | <hsivonen> | Hixie: is <keygen> not on the part of the Web that Google crawls? |
| 22:10 | <hsivonen> | <keygen> is hiding well for a tag that needs special attention |
| 22:13 | <Hixie> | it's on very few pages, i doubt it's on the same pages as <math> or <svg>. But I don't want the list of elements to be some half-assed list that has holes all over the place. |
| 22:13 | <Hixie> | that's the advantage of whitelisting -- we can _know_ that we have included all the elements in the current versions. |
| 22:14 | <hsivonen> | Sam seems to assume that whitelists would have to be frozen |
| 22:14 | <Hixie> | the problem with whitelists is that they have a terrible forward-compat story |
| 22:15 | <hsivonen> | if the parser falls out of "in namespace", yes |
| 22:15 | <annevk> | i'm not convinced of that terrible forward compat story as browsers will have to add support for the element first anyway before it can be useful |
| 22:16 | <annevk> | at which point it would need to be added to the HTML specification |
| 22:16 | <annevk> | s/would need to/could/ s/specification/parser/ |
| 22:16 | <Hixie> | consider <svg> <circle> <newFeature> </circle> <polygon/> </svg> |
| 22:16 | <Hixie> | in browsers that don't know about newFeature, the polygon doesn't render |
| 22:17 | <Hixie> | even if newFeature is just a new way of including metadata or some such thing that has no great user-visible effect |
| 22:17 | <annevk> | oh true, the error handling makes it nasty |
| 22:18 | <zcorpan_> | but would <newFeature> have to pop <svg>? |
| 22:18 | <annevk> | in that case some half assed list of elements perhaps collected through experiment would be fine with me :) |
| 22:18 | <annevk> | zcorpan_, if it's called <b> :) |
| 22:18 | <hsivonen> | a half-assed list of the most common legacy elements would work |
| 22:18 | <Hixie> | zcorpan_: if <newFeature> is an html element, i'd like it to, yes |
| 22:19 | <Hixie> | hsivonen: yeah, i think we'll end up just doing that |
| 22:19 | <Hixie> | i don't like half-assedness |
| 22:19 | <Hixie> | html is so half-assed already, i like cleaning it up, not making it worse :-) |
| 22:19 | <Philip`> | Is full-assedness better? |
| 22:20 | <annevk> | Hixie, arguably adding new features makes the format slightly worse :) |
| 22:20 | <annevk> | Hixie, given the magic element lists the parser already has I'm not really not that concerned about another one |
| 22:20 | zcorpan_ | goes off and makes an HTML+ 5 |
| 22:21 | <zcorpan_> | or is that HTML5+ ? |
| 22:21 | <annevk> | HTML5 3.0 |
| 22:23 | <annevk> | it's too bad btw that this new format doesn't have any easy to author features for math :( |
| 22:24 | <zcorpan_> | surely the mathml error handling also applies to mathml in xhtml5 -- not just text/html ? |
| 22:25 | <annevk> | Hixie, I moved <annotation-xml> per above |
| 22:26 | <bzed> | jgraham_: what's the status of the lxml fix? |
| 22:27 | <Hixie> | annevk: i thought we specifically never wanted normal html processing in <annotation-xml> |
| 22:27 | <annevk> | Hixie, alternative math content in annotation-xml has a <math> root |
| 22:28 | <Hixie> | no it doesn't |
| 22:28 | <annevk> | ooh |
| 22:28 | <Hixie> | read the spec :-) |
| 22:30 | <annevk> | hsivonen said "forwarding to secondary mode would work for SVG, MathML and HTML" |
| 22:30 | <annevk> | and there's no cat picture, so it must be true! |
| 22:32 | <annevk> | (reverted) |
| 22:33 | <annevk> | oh fun, annotation-xml can contain presentational Math too |
| 22:33 | <Hixie> | i can't find where the spec defines annotation-xml |
| 22:33 | <annevk> | and is then nested inside the <semantics> element which besides annotation-xml contains content MathML |
| 22:33 | annevk | reads examples |
| 22:34 | <annevk> | Hixie, http://www.w3.org/TR/MathML2/chapter4.html#contm.annotation-xml |
| 22:34 | <annevk> | (per the element index that is the place) |
| 22:35 | <Hixie> | hsivonen: well i'm just going to define that conformance checkers have to apply mathml and svg conformance checking as well. if you can't work out what mathml means, let me know, and i'll switch to a whitelist of just pres mathml. |
| 22:35 | <Hixie> | annevk: that doesn't define anything as far as i can tell |
| 22:36 | <annevk> | dunno, there's no RFC2119 usage |
| 22:36 | <Hixie> | i'm declaring this conveniently not my problem |
| 22:37 | <annevk> | i think it makes sense to whitelist descendents of <math> to pres math and leave annotation-xml open |
| 22:38 | <met_> | I know the 1st April passed, but still http://methisto.blogspot.com/2008/04/can-you-pass-acid-test.html |
| 22:39 | <hsivonen> | Hixie: my first concern is finding out what methodology you used to find out that Validator.nu's current MathML schema is wrong |
| 22:39 | <hsivonen> | Hixie: that is, can I use whatever methodology you used to fix it |
| 22:49 | <BenMillard> | annevk, blogged my e-mail and the reply about public-pfwg-comments here: http://projectcerbera.com/blog/2008/04#day03 |
| 22:51 | <annevk> | lol, for openness he asks you to take it up with the process document owner |
| 22:51 | <annevk> | as if it's likely that that will change in the immediate future |
| 22:58 | <hsivonen> | what are the different expectations? |
| 23:00 | <Hixie> | hsivonen: i read the schema and compared it to the spec |
| 23:00 | <hsivonen> | Hixie: ok |
| 23:00 | <Hixie> | also, the dtd mentions that it has two modes |
| 23:00 | <Hixie> | search for "strict" in the dtd |
| 23:02 | <hsivonen> | thanks |
| 23:16 | <jgraham> | bzed: I fixed the major issue but there are some minor things till to be done |
| 23:17 | <jgraham> | Which I had sort of forgotten about... |
| 23:17 | jgraham | has been quite busy |
| 23:18 | <BenMillard> | annevk, I guess he thought I was asking "why don't Member groups work like Public groups" when I was trying to ask "have you considered making PFWG a Public group?" |
| 23:19 | <annevk> | oh |
| 23:19 | <annevk> | maybe clarify then... |
| 23:20 | <Hixie> | http://lists.w3.org/Archives/Public/public-pfwg-comments/2008AprJun/0004.html |
| 23:22 | <jgraham> | Hixie: Haven't MathML and SVG been developed largely in Member space |
| 23:22 | <Hixie> | yes |
| 23:22 | <Hixie> | and we're not adopting them |
| 23:22 | <Hixie> | we're just pointing to them |
| 23:23 | <Hixie> | the part we're adopting is being developed openly |
| 23:23 | <jgraham> | the distinction seems subtle to me |
| 23:23 | <jgraham> | but since I agree with your desire for aria to be open... |
| 23:23 | <annevk> | it'd be the same for ARIA more or less |
| 23:23 | <Hixie> | the distinction is who is responsible for the conformance criteria |
| 23:23 | <BenMillard> | annevk, I already replied to him |
| 23:23 | <Hixie> | if we end up specifying aria in html5, then i am |
| 23:24 | <annevk> | I thought we'd just give all aria-* attributs and role to the ARIA people |
| 23:24 | <jgraham> | The fact that you can't even subscribe to public-pfwg-comments is slightly insane |
| 23:24 | <annevk> | it is, yes |
| 23:25 | <BenMillard> | Cooper's e-mail to me seems to suggest WAI-Xteh is the list for discussion |
| 23:25 | <Hixie> | annevk: i don't think they've shown an ability to define them well enough for that |
| 23:26 | <annevk> | compare with SVG |
| 23:27 | <Hixie> | i want to redefine svg too |
| 23:27 | <Hixie> | i just don't have the time |
| 23:28 | <annevk> | (fwiw, i applaud you for prioritizing and simply not taking on work all the time) |
| 23:29 | <Hixie> | heh |
| 23:31 | <BenMillard> | +1 |
| 23:35 | <heycam> | hi roc? |
| 23:35 | <roc> | hello |
| 23:36 | <heycam> | hey. i see you'll be coming to monash next week! |
| 23:36 | <roc> | yep! |
| 23:36 | <bzed> | jgraham: wha tdo you think when all will be fixed? |
| 23:36 | <heycam> | nice. look forward to meeting you there... |
| 23:37 | <roc> | I should have plenty of time to talk if there's something you want to talk about |
| 23:37 | <roc> | Australian universities tend not to pack visitor schedules as much as other places, for better or worse |
| 23:37 | <heycam> | :) |
| 23:37 | <heycam> | nothing in particular, but i always like putting faces to names |
| 23:41 | <jgraham> | bzed: I'll make sure it gets done at the weekend |
| 23:41 | <Hixie> | http://wiki.whatwg.org/wiki/New_Vocabularies is now updated to take into account the new proposla |
| 23:46 | <jgraham> | annevk, Hixie: Seriously, the aria spec barely specifies anything at all atm |
| 23:47 | <Hixie> | like i said |
| 23:47 | <Hixie> | :-) |
| 23:50 | <hober> | Does anyone know what "on the glass" means? |
| 23:51 | <annevk> | Hixie, the implicit MathML stuff is not going to work? |
| 23:52 | <annevk> | why was optional end tags rejected? |
| 23:56 | <bzed> | jgraham: great, thanks a lot. we have a debian bug squashing party at the weekend, so I'll have the time to update the package during that :) just ping me if I can test anything or help you |
| 23:56 | <jgraham> | bzed: great |
