| 00:00 | <annevk> | the copy source past into tool case will not work even if we don't simplify MathML at all |
| 00:00 | <jgraham> | Hixie: I think you underestimate the disconnect between MathML and what ordinary authors are capable of |
| 00:01 | <Hixie> | annevk: mozilla already supports exporting a mathml tree extracted from the dom |
| 00:01 | <Hixie> | annevk: i agree that in general the tools will need html parsers to do that though, at which point the only disconnect is the serialiser |
| 00:01 | <Hixie> | jgraham: if they can learn latex, they can learn mathml |
| 00:02 | <Hixie> | jgraham: it's just more verbose, not more complicated |
| 00:02 | <jgraham> | Hixie: If they know LaTeX and MathML is harder why would they bother? |
| 00:02 | <Hixie> | i do not think that the number of latex authors outweighs the number of mathml authors over the next 30 years. |
| 00:02 | <gsnedders> | Hixie: what way did you want me to help with indexing? |
| 00:03 | <Hixie> | gsnedders: nothing yet :-) |
| 00:03 | <gsnedders> | Hixie: s/did/will/ |
| 00:03 | <gsnedders> | :) |
| 00:03 | <jgraham> | I could be wrong but I find that hard to believe |
| 00:03 | <Hixie> | gsnedders: but eventually, if your tool can handle it, it'd be cool to have it autogenerate tables of elements, attributes, and that kind of thing |
| 00:03 | <gsnedders> | Hixie: Yeah, that would be :) |
| 00:04 | <jgraham> | I can't imagine any of the academics I know learning MathML if they can use LaTeX instead |
| 00:04 | <annevk> | that depends on whether or not we do the right thing with MathML :p |
| 00:04 | <jgraham> | Even if the result ends up as MathML they will use LateX->MathML |
| 00:04 | <Hixie> | jgraham: that's fine |
| 00:04 | <gsnedders> | jgraham: I couldn't move to anything from LaTeX, maths languages are too complex and not really worth learning another |
| 00:05 | <Hixie> | jgraham: but i believe if we put mathml into html, that going forwards we will see many people grow up on mathml |
| 00:05 | <jgraham> | Hixie: That's a tools will ave us argument :) |
| 00:05 | <jgraham> | s/ave/save/ |
| 00:06 | <Hixie> | jgraham: we're not putting actual latex into text/html, so if these authors aren't willing to do anything but latex, they will either use tools or won't use html (either of which are fine) |
| 00:07 | <jgraham> | Hixie: But it prevents people from starting to use it seriously |
| 00:07 | <jgraham> | (if they won't use html) |
| 00:07 | <jgraham> | So everyone will always have to learn LaTeX to be published |
| 00:08 | <Hixie> | jgraham: i've lost track of the antecedent of "it" and "they" |
| 00:08 | <gsnedders> | they are wrong, it is right. |
| 00:09 | <Hixie> | jgraham: if your primary use case is making people go from a latex workflow to a text/html workflow, and you have the constraint that people won't learn anything but latex, there is only one solution, and that's to allow latex in text/html. agreed? |
| 00:10 | <Hixie> | (impressive. the only conflict between mathml and html in terms of tag names is <image>. not bad for hundreds of tag names.) |
| 00:11 | <jgraham> | Hixie: My primary use case is getting mathematics on the web to be usable. I believe this requires that people who currently use LaTeX can easilly transition either their skills or their content to the web, which I think implies either judicious use of tools or a LaTeX-like syntax |
| 00:11 | <jgraham> | (but not necessarily exactly LaTeX) |
| 00:12 | <Hixie> | i don't understand why you believe that latex authors who are not willing to learn non-latex syntax form the primary relevant group of authors |
| 00:13 | <Hixie> | it seems like there is an unstated assumption in your argument |
| 00:14 | <h3h> | any plans to specify .pathname, .host, .hostname, .port, etc. on <a> elements? |
| 00:14 | <jgraham> | Because I presume that the primary group of authors are similar to the people who currently publish mathematics, who by-and-large use LaTeX |
| 00:14 | <annevk> | h3h, yes, they'll implement the Location interface in due course |
| 00:14 | <Hixie> | h3h: yeah, i just haven't hooked it up yet |
| 00:14 | <h3h> | neat |
| 00:14 | <Hixie> | they won't implement Location |
| 00:14 | <jgraham> | My experience with these people is that they are not very interested in learning new tools for old tasks |
| 00:14 | <annevk> | oh |
| 00:14 | <h3h> | there are some un-fun inconsistencies between browsers |
| 00:14 | <Hixie> | the attributes have been factored out |
| 00:15 | <Hixie> | same idea though |
| 00:15 | <Hixie> | jgraham: i agree. but i don't understand why you think that population is the main one. |
| 00:15 | <annevk> | oh right |
| 00:15 | <Hixie> | jgraham: in particular, i would have assumed that the many people who are yet to learn any syntax significantly outnumber the latex authors of today. |
| 00:17 | <jgraham> | Hixie: I think those people will still have to learn LaTeX (to use in paper-based or PDF-based publications) and will not want to learn a second sntax that is significantly more complex |
| 00:17 | <jgraham> | s/sntax/syntax/ |
| 00:17 | <Hixie> | jgraham: so why would they bother with html at all? |
| 00:17 | <Hixie> | jgraham: put it this way. why do we need latex syntax for maths but not paragraphs? |
| 00:18 | <Hixie> | and i really don't think that the majority of people writing maths on the web will be those publishing papers |
| 00:18 | <Hixie> | i'd expect those publishing papers to be a minority |
| 00:18 | <jgraham> | Hixie: Because HTML syntax or paragraphs isn't too bad. MathML syntax is orders of magnitude worse than LaTeX (which is already pretty annoying) |
| 00:19 | <jgraham> | Hixie: It is true that sub-degree level mathematics is a rather different case |
| 00:20 | <jgraham> | but expecting simpler maths to be published using a more complex syntax is not an obviously great idea |
| 00:21 | jgraham | -> bed |
| 00:21 | <jgraham> | goodnight |
| 00:21 | <Hixie> | jgraham: the long and short of it is that to address your use case we basically have to come up with a way to have the syntax of mathml in html be latex-compatible, which means significantly complex parsing rules, incomplete support for mathml, highly unintuitive styling and scripting behaviour, either freaky serialisation rules or no round-tripping behaviour, an inconsistent language, and trading in verbosity for complexity |
| 00:21 | <Hixie> | nn |
| 00:21 | <Hixie> | which i'm not sure really is a good trade |
| 00:24 | Philip` | wonders what that proof thing is called where you write a logical statement at the bottom then put a line above it and write the statements needed to prove the first one, and recurse upwards until you end up with axioms at the top |
| 00:24 | Philip` | then wonders if MathML can do that |
| 00:25 | <annevk> | ah, yes, "URI decomposition attributes " |
| 00:26 | <othermaciej> | Philip`: isn't that called a "proof"? |
| 00:26 | <othermaciej> | (except that one might imagine starting from the axioms when writing your proof instead) |
| 00:26 | <annevk> | it's a specific type of proof |
| 00:27 | <Philip`> | It's a specific presentation for proofs, in particular |
| 00:27 | <othermaciej> | well, whether you logically started from the bottom and wrote upwards or vice versa is not relevant when presenting the result |
| 00:28 | <othermaciej> | so I guess it is only the lines between in particular that may be special |
| 00:28 | <Hixie> | hsivonen: i think there's a bug in your mathml schema |
| 00:30 | <Hixie> | hm, the dtd allows it too |
| 00:30 | <Hixie> | that makes no sense |
| 00:30 | <Philip`> | Oh, it's kind of like http://en.wikipedia.org/wiki/Rule_of_inference |
| 00:30 | <Hixie> | <mrow><none/><mprescripts/></mrow> is surely invalid |
| 00:30 | <Philip`> | with 'premises (horizontal line) conclusion', and '(horizontal line) axiom' |
| 00:31 | <Philip`> | and it sounds like system that doesn't have any particularly compelling name |
| 00:31 | <Philip`> | s/system that/that system/ |
| 00:32 | <Hixie> | wtf |
| 00:32 | <Hixie> | the mathml dtd explicitly doesn't check certain things |
| 00:32 | <Hixie> | that makes no sense to me |
| 00:33 | <gsnedders> | Like what? |
| 00:33 | <Hixie> | <mrow><none/><mprescripts/></mrow> |
| 00:34 | <gsnedders> | heh. |
| 00:34 | gsnedders | ought to go sleep |
| 00:34 | gsnedders | is meant to be hill-walking tomorrow |
| 00:35 | <gsnedders> | (despite having CFS) |
| 00:35 | <Hixie> | wtf is: |
| 00:35 | <Hixie> | <!ENTITY % prscrPresExpression " (%onePresExpression;, |
| 00:35 | <Hixie> | ((%onePresExpression;|%none.qname;),(%onePresExpression;|%none.qname;))*, |
| 00:35 | <Hixie> | (%mprescripts.qname;, |
| 00:35 | <Hixie> | ((%onePresExpression;|%none.qname;),(%onePresExpression;|%none.qname;))*)? |
| 00:35 | <Hixie> | )"> |
| 00:35 | <Hixie> | christ |
| 00:35 | <Hixie> | some people |
| 00:35 | <gsnedders> | SGML-- |
| 00:35 | <gsnedders> | XML-- |
| 00:35 | <Hixie> | would it kill them to write this without eighteen levels of redirection |
| 00:36 | <gsnedders> | Yes, it wouldn. |
| 00:36 | <gsnedders> | *would |
| 00:36 | <Hixie> | what's the comma in sgml anyway |
| 00:36 | <Hixie> | isn't in just "and"? |
| 00:36 | Philip` | wonders if you get much exponential growth when expanding out all the entities |
| 00:36 | <Hixie> | oh, i get it |
| 00:37 | <Hixie> | duh |
| 00:37 | <gsnedders> | Hixie: followed |
| 00:37 | <Hixie> | i forgot that the base had to be there |
| 00:37 | <Dashiva> | Looks like they could've benefitted from + instead of just * :) |
| 00:38 | <Hixie> | no, * is right |
| 00:38 | <Dashiva> | Yeah, but x+ would be a lot easier on the eyes than xx*. Probably isn't part of the syntax, though. |
| 00:39 | <Hixie> | it isn't xx* |
| 00:39 | <Dashiva> | It's not? |
| 00:39 | <Hixie> | it's "a (x x)* [b (x x)*]" |
| 00:39 | <Dashiva> | Ah, I must've misread the parentheses |
| 00:40 | <Dashiva> | I suppose that's another vote for the unreadability of it (or my level of sleepiness) |
| 00:41 | <gsnedders> | ooo. April 1st now! |
| 00:41 | <Hixie> | ok i think i have summarised the presentational mathml syntax |
| 00:41 | <Hixie> | it's not tooooo bad |
| 00:41 | <gsnedders> | Disclaimer: Anything I say today i probably bullshit. |
| 00:41 | <Dashiva> | gsnedders: bullshit |
| 00:41 | <gsnedders> | Dashiva: Don't fuck around with me, I'm a huge strong guy. |
| 00:42 | <gsnedders> | 42 y/o policemen from Alabama. |
| 00:42 | <Dashiva> | I'm looking forward to the whatwg blog post |
| 00:42 | <Dashiva> | Hope this years' will be as good as the previous one |
| 00:42 | <Dashiva> | *year's |
| 00:42 | gsnedders | gets dragged in to looking at suicide girls from a bug report. |
| 00:42 | <gsnedders> | Ergh. |
| 00:42 | <gsnedders> | (says the emo guy) |
| 00:44 | <Hixie> | http://junkyard.damowmow.com/308 |
| 00:46 | gsnedders | has to run off on call |
| 00:48 | <h3h> | quick test case for the <a> properties: http://xkr.us/bugs/link-properties-test.html |
| 00:49 | <h3h> | as it's written Firefox (2.0.x) is the only browser to pass |
| 00:50 | <Dashiva> | What other browsers did you test? |
| 00:50 | <h3h> | heh. IE doesn't even print results. |
| 00:50 | <h3h> | Opera 9.2.x, IE 7, Safari 3.1 |
| 00:51 | <h3h> | though I just assume those expected values are correct |
| 00:51 | <h3h> | in absence of a spec |
| 00:52 | <Dashiva> | There's also the issue of the read/write-ability of the properties |
| 00:52 | <h3h> | you can extend the test :) |
| 00:52 | <Dashiva> | I did a test on these properties a while back, and the results were all over the place |
| 00:52 | <Dashiva> | So I figured nobody uses them |
| 00:53 | <h3h> | I did last week |
| 00:53 | <h3h> | and had to come up with a normalization routine |
| 00:53 | <h3h> | var path = '/' + el.pathname.replace(/^\/?([^\?]+).*/, "$1"); |
| 00:53 | <Dashiva> | I pondered using a strange URL for the testcase and copying that URL onto a link, so you could compare the location properties and link properties both in one |
| 00:54 | <h3h> | yeah, it's worth testing them on the location object itself too |
| 00:54 | <Dashiva> | h3h: http://dashiva.net/test/anchorprop.html |
| 00:54 | <h3h> | but separate |
| 00:54 | <h3h> | naet |
| 00:54 | <h3h> | er neat |
| 00:55 | <h3h> | Christmas in Opera :) |
| 00:55 | <Dashiva> | Ayup |
| 00:55 | <Dashiva> | It's odd that both opera and safari have switched host and hostname |
| 00:56 | <h3h> | yeah, unsettling |
| 00:56 | <h3h> | IE is almost all green... |
| 00:56 | <Dashiva> | IE is all green, except that I decided the "correct" path had a / first |
| 00:56 | <Dashiva> | So it gets two red for that |
| 00:56 | <h3h> | yeah |
| 00:57 | <Dashiva> | Safari treats the properties as readonly, opera allows writing but doesn't change href, IE and FF are fully readwrite |
| 00:58 | <h3h> | you have all sorts of fun tests in here |
| 00:58 | <Dashiva> | And I can't tell you what half of them are supposed to test |
| 01:01 | <Hixie> | hm, here's one problem with implying <mo>, etc, open tags |
| 01:01 | <Hixie> | <mrow> <mn> 1 + 2 </mn> </mrow> vs <mrow> 1 + 2 </mrow> |
| 01:01 | <Hixie> | in the second one, we want the + to close the <mn> |
| 01:01 | <Hixie> | but how do we know if the <mn> was implied or not? |
| 01:02 | <Hixie> | that would be very different from past implication behaviour |
| 01:02 | <Hixie> | maybe we should only allow end tags to be omitted |
| 01:02 | <Dashiva> | Is <mn>1+2</mn> meaningful? |
| 01:03 | <Hixie> | probably not, but 1.2 is |
| 01:04 | <mpt> | You're respecifying MathML now? |
| 01:04 | <Dashiva> | Yeah, that's the problem with determining what's a decimal sign and what's an operator |
| 01:05 | <Hixie> | mpt: we're looking into embedding mathml into text/html |
| 01:08 | <Hixie> | hey, we can omit end tags pretty well |
| 01:11 | <Dashiva> | Without requiring reparsing? |
| 01:11 | <Hixie> | http://wiki.whatwg.org/wiki/Equations_in_HTML |
| 01:17 | <tomg> | http://www.neowin.net/news/main/08/03/31/microsoft-to-snub-standards-compliant-mode-in-ie8 :) |
| 01:18 | Hixie | turns off his news filters for the next 36 hours |
| 01:18 | <tomg> | heh |
| 01:19 | <roc> | Hixie, it seems slightly dodgy that you're putting multiple elements on a line in the new syntax but not the old syntax |
| 01:20 | <othermaciej> | tomg: wait, does that mean switching the default back, or removing IE8 standards mode entirely? |
| 01:20 | <roc> | uh |
| 01:20 | <roc> | *that* would be exciting |
| 01:20 | <othermaciej> | oh |
| 01:20 | othermaciej | realizes this post is probably meant for tomorrow |
| 01:20 | <tomg> | it's rather lame that there's 03/31 in that article |
| 01:21 | <Hixie> | roc: i'm writing them out the way i would write them out if i were writing using those syntaxeus |
| 01:21 | <tomg> | it is tomorrow here, though |
| 01:21 | <tomg> | i think. |
| 01:22 | <roc> | I hate hate HATE this stupid day |
| 01:22 | <Hixie> | roc: (reload) |
| 01:22 | <tomg> | it'll be over soon. |
| 01:23 | <tomg> | or less soon if it hasn't begun for you yet. |
| 01:23 | <roc> | it has |
| 01:24 | <roc> | but it's not over until California goes away |
| 01:25 | <Philip`> | It won't be over for several days more, while people keep pointing you at fake news articles accidentally |
| 01:26 | <roc> | it should be illegal |
| 01:26 | <Hixie> | what should? |
| 01:26 | <Hixie> | lying? |
| 01:26 | <Hixie> | misleading people? |
| 01:26 | <Philip`> | I think there are laws against making it illegal |
| 01:26 | <roc> | pissing me off |
| 01:26 | <Hixie> | heh |
| 01:27 | <Philip`> | At least it's a potentially-useful reminder that not everything you read on the internet is true, regardless of what day it is |
| 01:28 | <Hixie> | oh btw, if anyone is going to do a whatwg one, what i said last year still holds |
| 01:28 | <Hixie> | you have to have a real blog post to post on the 2nd |
| 01:28 | <Dashiva> | We could solve it like this: http://www.theonion.com/content/node/29601 |
| 01:45 | <Hixie> | http://damowmow.com/temp/mml is a list of all mathml2 elements, i think |
| 02:57 | <Hixie> | well |
| 02:57 | <Hixie> | svg is sure going to be more of a pain |
| 02:57 | <Hixie> | it has camelCase tag names |
| 02:57 | <Hixie> | and 6 tag name conflicts |
| 02:58 | <Hixie> | i guess we can make <a> automatically end up in the right namespace |
| 02:58 | <Hixie> | based on the parent element |
| 02:58 | <Hixie> | <font> is more of an issue though |
| 02:58 | <Hixie> | oh wait, that's to define a font |
| 02:59 | <Hixie> | maybe we can just throw all of that out in the text/html variant |
| 02:59 | <Hixie> | <script> and <style> can just use the right namespace automagically |
| 02:59 | <Hixie> | that leaves <title> and <image> |
| 03:00 | <Hixie> | so. tempting. to fix svg. |
| 03:03 | <Hixie> | christ. svg tiny 1.2 has only 47 elements to svg 1.1's 81, yet manages to have 2 extra tag name conflicts |
| 03:04 | <othermaciej> | SVG "Tiny" |
| 03:04 | <othermaciej> | "tiny" like a mob nickname |
| 03:05 | <Hixie> | http://www.w3.org/TR/SVGMobile12/script.html#HandlerElement |
| 03:05 | <Hixie> | that seems like something that as a spec editor, if i was writing it, it would immediately raise big red flags |
| 03:06 | <Hixie> | "in the new and smaller version of this language, you must make your documents must more complex" |
| 03:08 | <Hixie> | svg 1.1 u svg 1.2 has 92 element types |
| 03:08 | <Hixie> | with 9 name clashes |
| 03:09 | <Hixie> | svg is as bad as html |
| 03:10 | <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) |
| 03:10 | <Hixie> | etc |
| 03:11 | <Hixie> | definition-src is especially funny because there's an element <defs> so they've already shortened "definition" once, but "src", which is shorter than "definition", is the word that gets shortened |
| 03:11 | <heycam`> | :) |
| 03:12 | <heycam`> | tho definition-src was probably chosen to match the css descriptor name |
| 03:13 | <Hixie> | which one? |
| 03:14 | <Hixie> | it's love-hate relationship with svg is one of the biggest annoyances with svg |
| 03:14 | <Hixie> | half the time it pretends css doesn't exist, and the other half of the time, it relies on it |
| 03:14 | <Hixie> | while simultaneously breaking it (unitless numbers anyone) |
| 03:14 | <heycam`> | http://www.w3.org/TR/REC-CSS2/fonts.html#descdef-definition-src ? |
| 03:15 | <Hixie> | oh christ, svg adopted the disaster that is css2's fonts stuff? |
| 03:15 | <heycam`> | in retrospect yes the use of unitless numbers for font-size was needlessly incompatible with css |
| 03:15 | <heycam`> | but tiny fixed that to some extent |
| 03:15 | <Hixie> | hey i complained about that issue before svg 1.0 was in CR, iirc |
| 03:16 | <Hixie> | so it wasn't just a mistake in retrospect :-) |
| 03:17 | <heycam`> | did css 2.1 drop that font stuff? in lieu of the css3 font stuff? |
| 03:17 | <Hixie> | yeah, on the basis that it sucked and nobody implemented it anyway |
| 03:17 | <Hixie> | i notice SVG 1.1's definition of definition-src is just as worthless as CSS2's, heh |
| 03:17 | <Hixie> | i'd love to see the tests that proved interop enough to exit CR for _that_ feature :-) |
| 03:18 | <heycam`> | jet:~/work/cvs/w3/WWW/Graphics/SVG/Group/repository/testsuite/1.1/svg $ grep 'definition-src' * | wc -l |
| 03:18 | <heycam`> | |
| 03:18 | <Hixie> | i rest my case :-) |
| 03:19 | <Hixie> | i really don't know where to begin on allowing svg in text/html |
| 03:19 | <heycam`> | i don't disagree that the 1.1 test suite was lacking |
| 03:19 | <Hixie> | mathml is easy compared to this, heh |
| 03:19 | <heycam`> | what's the toughest problem? the camel case stuff? |
| 03:19 | <Hixie> | no that's trivial |
| 03:19 | <Hixie> | it's the name clashes that pose the biggest problem |
| 03:19 | <Hixie> | that and the fact that there's so many elements |
| 03:19 | <heycam`> | svg:title vs html:title? |
| 03:20 | <Hixie> | for instance |
| 03:20 | <heycam`> | i'm against having tricky tag implication for svg |
| 03:20 | <heycam`> | it's difficult enough for me to know which tags are implied for html |
| 03:21 | <Hixie> | the clashing elements are: a audio font image script style textArea title video |
| 03:21 | <Hixie> | i don't think tag inference makes sense for svg |
| 03:21 | <heycam`> | if only we had some sort of... namespacing mechanism? :) |
| 03:21 | <Hixie> | namespaces are dumb |
| 03:21 | <Hixie> | in this kind of context |
| 03:21 | <heycam`> | i don't think namespaces are dumb. there may be aspects of xml namespaces that are dumb. |
| 03:21 | <Hixie> | svg's verbosity problem isn't in the number of elements |
| 03:21 | <othermaciej> | namespaces are neat, xml namespaces suck eggs |
| 03:22 | <Hixie> | namespaces make sense for programmers |
| 03:22 | <annevk> | namespaces on the Web don't make sense |
| 03:22 | <Hixie> | they are dumb in a document authoring format |
| 03:22 | <heycam`> | i do agree that their promise of magical extensibility doesn't really fly |
| 03:23 | <annevk> | hehe, public-cdf... |
| 03:23 | <Hixie> | svg's main problem is it has too many features |
| 03:23 | <Hixie> | i mean wtf is <altGlyphItem> |
| 03:23 | <Hixie> | there is _so_ no need for that on the web |
| 03:23 | <othermaciej_> | namespaces as a prefix with collision avoidance by registry or convention would be fine |
| 03:23 | <heycam`> | there is some weirdness in there with the altglyph stuff |
| 03:23 | <heycam`> | underdescribed in the fonts chapter |
| 03:23 | <othermaciej> | Hixie: you just made me implement alt glyphs, you bastard!!! |
| 03:24 | <othermaciej> | *now* you tell me it's an excess feature |
| 03:24 | <heycam`> | and probably not solving any real solutions |
| 03:24 | <Hixie> | othermaciej: blame heycam :-) |
| 03:24 | <heycam`> | altGlyph isn't too bad, alyGlyphItem is probably unnecessary |
| 03:24 | <Hixie> | i wonder if we can get away with removing many of these features in the text/html serialisation |
| 03:24 | <heycam`> | i don't think many svg-oriented people would be in favour of that |
| 03:25 | <Hixie> | i don't expect any of this to be popular with svg people |
| 03:25 | <Hixie> | just like i'd hate it for the svg group to take something like text layout and make a tiny subset of that and put it in svg 1.2 |
| 03:26 | <shepazu> | I don't think HTML5 needs to specify anything about vector graphics or math... that work's been done elsewhere... HTML5 just needs to define a point of extensibility |
| 03:27 | <Hixie> | sadly, nobody has yet suggested a plausible extension mechanism that doesn't involve hardcoding a bunch of tag names |
| 03:27 | <Hixie> | (which is the approach i'm therefore taking) |
| 03:27 | <heycam`> | Hixie, is that because of the naming conflicts? |
| 03:27 | othermaciej | wonders what Hixie will come up with for XBL |
| 03:27 | <othermaciej> | (if anything) |
| 03:27 | <Hixie> | othermaciej: i don't plan to solve that problem |
| 03:28 | <Hixie> | heycam`: partly |
| 03:28 | <Hixie> | heycam`: the biggest problem is that there are many html documents out there today that use all matter of weird tag names |
| 03:28 | <shepazu> | simply having an element like <ext> </ext> would seem to solve the problem nicely... |
| 03:28 | <heycam`> | or the IE <xml> element? |
| 03:28 | <shepazu> | (or some tag that isn't known to have conflicts) |
| 03:28 | <othermaciej> | why not the IE <xml> element? |
| 03:28 | <othermaciej> | as an escape to XML parsing? |
| 03:29 | <othermaciej> | not that I love that |
| 03:29 | <othermaciej> | but I wonder what fails to work about it |
| 03:29 | <shepazu> | (rather, is known not to have conflicts) |
| 03:29 | <heycam`> | othermaciej, yeah |
| 03:29 | <Hixie> | heycam`: so for example, if we said "when you see <ext> you just start parsing elements using this particular process instead" then any pages that happen to hit that would stop working |
| 03:29 | <othermaciej> | (other than IE assuming that content won't render) |
| 03:29 | <heycam`> | you can't nest html5 inside there, at least |
| 03:29 | <heycam`> | sorry i mean you can't nest html5 with another <xml> element in there |
| 03:29 | <heycam`> | since it has <script>-like parsing |
| 03:29 | <shepazu> | right |
| 03:29 | <heycam`> | but apart from that, it seems ok to me |
| 03:29 | <Hixie> | othermaciej: well apart from it being incompatible with IE, which is a blocker problem, it also prevents you from doing things like nested content |
| 03:30 | shepazu | didn't know about IE's <xml> element |
| 03:30 | <Hixie> | which is also a blocker problem |
| 03:30 | <Hixie> | (it's also not xml-compatible parsing in IE) |
| 03:30 | <Hixie> | (though i forget the details) |
| 03:30 | <heycam`> | Hixie, but what about having an svg context, where once you're inside an <svg> element, you can prefer the svg elements? |
| 03:30 | <shepazu> | Hixie: what about working to define <foreignElement> and the like, for nested content? |
| 03:30 | <othermaciej> | IE's <xml> doesn't parse as XML? yuck :-( |
| 03:30 | <heycam`> | surely there wouldn't be many pages that randomly use <altGlyph> but also inside an <svg> element, e.g. |
| 03:31 | <othermaciej> | shepazu: a google for "xml data islands" should find it |
| 03:31 | <Hixie> | heycam`: that's basically what i'm looking at doing |
| 03:31 | <heycam`> | Hixie, cool that should be useful information then |
| 03:31 | <Hixie> | but for what it's worth, the devil in all of these suggestions is in the details |
| 03:31 | <shepazu> | othermaciej: yes, just did that :) |
| 03:31 | <shepazu> | that's how ASV did inline SVG in IE |
| 03:31 | <heycam`> | Hixie, did you mean doing a study on the use of coincidentally svg-named elements are used in html? |
| 03:31 | <Hixie> | i've looked at many ideas similar to what all of you are proposing here, but always run into blocker issues when trying to define the details |
| 03:31 | <heycam`> | Hixie, or having an svg context for parsing? |
| 03:32 | <Hixie> | the latter |
| 03:32 | <heycam`> | ok |
| 03:32 | <shepazu> | http://developer.mozilla.org/en/docs/Using_XML_Data_Islands_in_Mozilla |
| 03:32 | <heycam`> | Hixie, it'd be great if you could document these problems somewhere (wiki?), since it seems to be a suggestion that a few people come up with |
| 03:32 | <heycam`> | and these people (including me) probably don't know about the details that may make it fail to work |
| 03:33 | <Hixie> | that would be a lot of work |
| 03:33 | <othermaciej> | you can also smuggle XML in a <script> element |
| 03:33 | <heycam`> | but you've done the work, right? of determining why it doesn't work? |
| 03:33 | shepazu | wonders if IE itself might change its behavior |
| 03:33 | <othermaciej> | Hixie: can you help us figure out why it doesn't work, so we can record for posterity? |
| 03:33 | <Hixie> | heycam: i haven't written it down, most of my design work is done in the shower |
| 03:33 | <shepazu> | they seem rather eager to move on in some cases |
| 03:33 | <othermaciej> | I'd be happy to write it up |
| 03:33 | <heycam`> | Hixie needs an electronic whiteboard in his shower... |
| 03:34 | <shepazu> | Hixie: use soap to write on the shower curtain :) |
| 03:34 | <othermaciej> | data islands expect their content to form its own DOM document |
| 03:34 | <othermaciej> | at least in IE |
| 03:34 | <othermaciej> | perhaps that is the blocker |
| 03:34 | <heycam`> | othermaciej, yeah i did notice that (a #document node in the live dom viewer) |
| 03:35 | <shepazu> | IE is changing its behavior in other ways, such as the event flow |
| 03:35 | <othermaciej> | wait, it makes the document node a child of an element?? |
| 03:35 | <heycam`> | yeah |
| 03:35 | <othermaciej> | !!!!@!#$%!#% |
| 03:35 | <heycam`> | :) |
| 03:35 | <heycam`> | conceivably there is content out there that calls getElementById() on that document node too, so you'd need to be careful if that were changed |
| 03:35 | <shepazu> | well, if <xml> won't fly, then maybe another element name |
| 03:36 | othermaciej | rubs his eyes and blinks in disbelief |
| 03:36 | <shepazu> | <xdi> |
| 03:36 | <heycam`> | shepazu, there is the <script> thing that othermaciej mentioned (and that rubys was using at one point) |
| 03:36 | <heycam`> | seems a bit of a hack though, with that name |
| 03:36 | <othermaciej> | <script> is your next-best bet, but then you can't nest script elements |
| 03:36 | <heycam`> | same as <xml> |
| 03:36 | <shepazu> | yeah, I didn't like that solution |
| 03:36 | <Hixie> | feel free to send fully concrete proposals (down to the level of fixing the tokeniser and tree construction parts of the spec) to the mailing-list. if you manage to get it to that level of detail without running into problems, then it's worth considering. i haven't succeeded in finding any generic mechanism that survives that level of detail. |
| 03:37 | <Hixie> | and no offense, but i really don't want to walk you all through your ideas until we find the problems :-) |
| 03:37 | <heycam`> | Hixie, sure but i think there are few people on the list who are well versed in exactly how the tokeniser and tree construction works |
| 03:37 | <shepazu> | I think this is worth the SVG WG looking into |
| 03:38 | <shepazu> | hsivonen might could help |
| 03:38 | <othermaciej> | Hixie: I believe you that there are problems but I want to record what they are (I am satisfied that I understand the problem with <xml>) |
| 03:38 | <othermaciej> | hsivonen could probably help flesh out ideas, yes |
| 03:38 | <heycam`> | there is certainly a lot of knowledge that you, othermaciej, hsivonen, etc. have about html parsing and the reasons for things having to be a certain way that aren't documented, and that many other people on the group don't know |
| 03:38 | <othermaciej> | actually <xml> is adequate to be an inline solution for XML, other than the fucking insanity of making a document node a child node |
| 03:38 | <othermaciej> | er |
| 03:38 | <othermaciej> | for XBL2 |
| 03:39 | <annevk> | HTML parsing is pretty well documented now :) |
| 03:39 | <heycam`> | annevk, but not the reasons for various things |
| 03:39 | <othermaciej> | heycam`: I'm happy to help people step through proposals enough to flesh them out |
| 03:39 | <annevk> | is there a wiki page with brief proposals? |
| 03:39 | <annevk> | yeah, I'm willing to help pointing out issues too |
| 03:39 | <othermaciej> | I don't understand IE's namespaces enough to totally get why using that won't work as a pseudo-extensibility hack, I guess probably the fact that Office inserts crazy namespaced tags |
| 03:40 | <othermaciej> | annevk: we should probably start a wiki page with proposals and their known showstopper problems |
| 03:40 | <heycam`> | othermaciej, that'd be great |
| 03:40 | <othermaciej> | (perhaps smart people will think of a way around some of those problems) |
| 03:40 | <annevk> | or don't see the problem... |
| 03:41 | <annevk> | but i'm fine with doing this :) |
| 03:41 | <heycam`> | if they don't see the problem, after viewing the wiki page, it's probably because there's some assumption that they and you don't share :) |
| 03:41 | <heycam`> | like, that xml sucks or something :) |
| 03:42 | <annevk> | i'll try to refrain from using that argument :p |
| 03:42 | <heycam`> | heh |
| 03:42 | <heycam`> | tbh i think that is the cause of a lot of the conflict between people in the group |
| 03:42 | <heycam`> | not xml in particular |
| 03:42 | <othermaciej> | annevk: even if it just stops people from bringing up solutions with known flaws, that would be a useful service |
| 03:42 | <heycam`> | but unstated assumptions about what is "good" or "bad" |
| 03:43 | <annevk> | it seems that the math guys mostly find the roundtripping to be problematic |
| 03:43 | <othermaciej> | I don't think Hixie would be looking at SVG at all if he was going solely by his own aesthetic preferences |
| 03:43 | <annevk> | they don't really care what the final syntax looks like I get the feeling |
| 03:43 | <shepazu> | I suggest the <aiui> element |
| 03:44 | <Hixie> | othermaciej: no kidding |
| 03:44 | <heycam`> | many people probably assume that it'd be easy to stick an extensibility point into html to allow inline svg etc. |
| 03:44 | <heycam`> | as shepazu suggested |
| 03:45 | <heycam`> | and so they probably don't think it's a big deal for you (as editor) |
| 03:45 | <heycam`> | s/it's/it should be/ |
| 03:45 | <heycam`> | but if the devil really is in the details, well then hopefully this wiki page can help |
| 03:45 | <othermaciej> | I must admit I do not know of a plausible generic extensibility point that would work for cut&pasting of totally as-is SVG |
| 03:45 | <Hixie> | (actually, going all the way to tokeniser/tree construction is probably unnecessary -- just some examples of source markup and how they should parse would be enough in most cases) |
| 03:45 | <heycam`> | othermaciej, sure, at least just because you can have whacky namespace prefixes |
| 03:45 | <heycam`> | defined outside the svg fragment |
| 03:46 | <othermaciej> | heycam`: that's not the kind of problem I am thinking of |
| 03:46 | <othermaciej> | I mean more like the just-discussed problems with <xml> |
| 03:46 | shepazu | agrees that part of the larger solution is working with SVG authoring tools to sanitize and sanify SVG output |
| 03:46 | <othermaciej> | and the fact that using <script>, you can't nest <script> tags, which could be a bummer for inline SVG certainly |
| 03:46 | <heycam`> | othermaciej, it not being able to contain another <xml>? |
| 03:46 | <othermaciej> | heycam`: no, the fact that it parses as a document node |
| 03:46 | <heycam`> | othermaciej, yeah that's a good point (about <script>) |
| 03:46 | <othermaciej> | in IE |
| 03:46 | <heycam`> | othermaciej, oh, that too :) |
| 03:47 | <shepazu> | for instance, there's really no need for all those crazy Inkscape namespaces |
| 03:47 | <othermaciej> | and that IE's namespaces probably can't be emulated due to office-generated HTML inserting <o:p> tags |
| 03:47 | <othermaciej> | or whatever |
| 03:47 | <othermaciej> | which non-IE browsers need to just ignore |
| 03:47 | <Hixie> | http://wiki.whatwg.org/wiki/Diagrams_in_HTML |
| 03:47 | <Hixie> | add examples to that page |
| 03:47 | <heycam`> | othermaciej, that office namespace stuff sounds like a good candidate for wiki-ing up too |
| 03:47 | <shepazu> | I wonder if the MS Office Live people would be interested in working on this problem? |
| 03:47 | <othermaciej> | heycam`: I don't know all the details on that one |
| 03:47 | <othermaciej> | (annevk might) |
| 03:48 | <othermaciej> | shepazu: sadly there is a shitload of Office-generated content on the web already |
| 03:48 | <othermaciej> | some office fake namespaced tags are more common than some real html tags |
| 03:48 | <shepazu> | yeah, but I think they are starting to take a different approach |
| 03:48 | <Hixie> | i expect lots of examples of how you want to have a generic mechanism on that page when i get back from dinner. :-) http://wiki.whatwg.org/wiki/Diagrams_in_HTML |
| 03:48 | <shepazu> | lol... will do, Hixie |
| 03:48 | <heycam`> | Hixie, i don't have the bandwidth to do that today unfortunately. maybe on the weekend. |
| 03:48 | <heycam`> | s/today/this week/ |
| 03:48 | <othermaciej> | I gotta go |
| 03:49 | shepazu | hopes Hixie has a long dinner.... like, 2 weeks |
| 03:49 | <heycam`> | heh |
| 03:49 | <othermaciej> | I will write up problems with some generic "new vocabulary" approaches later if I can |
| 03:49 | <Hixie> | i really hope to have this written up and specced by friday |
| 03:49 | <heycam`> | hmm |
| 03:49 | <Hixie> | i've been stuck on this for several weeks already |
| 03:49 | <Hixie> | (for what it's worth) |
| 03:50 | <annevk> | hmm, the MathML stuff digressed a bit, now I have to learn it better to write down 2+2=5 |
| 03:50 | <Hixie> | of course, if people find amazing ways of doing this that work better than what the spec ends up being, it can always change |
| 03:50 | <othermaciej> | I do kind of like the aria- and data- namespace-by-convention approach for attributes |
| 03:50 | <annevk> | though given the arguments from JD it's prolly ok |
| 03:50 | <heycam`> | Hixie, in essence what will the spec end up being if there is no other suggestion? |
| 03:50 | <Hixie> | heycam`: for svg? i dunno |
| 03:50 | <annevk> | data- is toaly nice |
| 03:50 | <Hixie> | heycam`: probably a hard-coded list of tag names and attribute names |
| 03:50 | <shepazu> | does mathml have a way of validating evaluated content? that would be interesting |
| 03:51 | <Hixie> | heycam`: and special rules for each one |
| 03:51 | <othermaciej> | data- will be very nice for microformats |
| 03:51 | <othermaciej> | brb |
| 03:51 | <heycam`> | Hixie, hopefully not hard coding for every single tag/attribute |
| 03:51 | <Hixie> | heycam`: only the camelCase ones and the ones in other namespaces, i expect |
| 03:52 | <heycam`> | Hixie, what about defaulting to the svg ones in an "svg context", and having a way to get back to an "html context" if you need e.g. html <textarea>? |
| 03:53 | <shepazu> | well, I expect we can keep revisiting this issue until a common solution is reached... there's plenty more to work on in HTML, I expect |
| 03:53 | <shepazu> | we have until 2018, right? |
| 03:53 | <heycam`> | =) |
| 03:53 | <annevk> | for some overlapping tags you can prolly just default to the HTML one, such as html:a |
| 03:53 | <annevk> | should work fine around SVG |
| 03:53 | <annevk> | although... |
| 03:53 | <Hixie> | heycam`: that runs into the problem i mentioned before -- what if a page with a form in it has a random <svg> element strewn in the middle? |
| 03:54 | <heycam`> | Hixie, hmm |
| 03:54 | <Hixie> | shepazu: 2012 for CR, according to my timetable |
| 03:54 | <heycam`> | Hixie, exercise your google webpage research fu, plz! |
| 03:54 | <shepazu> | that's why I think the <ext> element would be best |
| 03:55 | <Hixie> | heycam`: what should i search for? |
| 03:55 | <annevk> | what if a random page uses <ext>? |
| 03:55 | <shepazu> | any stray <svg>s are ignored or treated in an different manner |
| 03:55 | <Hixie> | shepazu: describe what you are proposing: http://wiki.whatwg.org/wiki/Diagrams_in_HTML |
| 03:55 | <Hixie> | or rather, just give several examples of it |
| 03:55 | <shepazu> | annevk, yeah, that's just a placeholder name, not a real suggestion |
| 03:55 | <heycam`> | things like that (an <svg> element that seems to contain html-ish stuff rather than svg-ish stuff, fsvo "seems to") |
| 03:55 | <heycam`> | anyway, gotta get back to real work :( |
| 03:55 | <annevk> | the question really goes for any name :) |
| 03:56 | <shepazu> | annevk: true, but we could find a name without existing conflicts |
| 03:56 | <shepazu> | we have google |
| 03:56 | <Hixie> | heycam`: if you have any concrete ideas of what i should search for, i can look... not sure how to do what you describe |
| 03:56 | <shepazu> | and still, we can define a processing model in case of future conflicts |
| 03:57 | <annevk> | it seems fairly ugly to me |
| 03:57 | <Hixie> | seriously though. i'll happily consider concrete proposals, even in just the form of examples on that wiki page or by e-mail or something |
| 03:57 | <Hixie> | irc isn't the ideal medium for that though. |
| 03:57 | <shepazu> | sure |
| 03:58 | <shepazu> | we'll work on it |
| 03:58 | annevk | adds the idea from shepazu to the wiki |
| 03:58 | <shepazu> | thanks, annevk |
| 04:00 | <annevk> | feel free to check it |
| 04:00 | <annevk> | it's there now |
| 04:01 | <annevk> | maybe i should have used a prefix to make it more clear |
| 04:03 | <Hixie> | edited |
| 04:04 | <annevk> | do you think we can imply <foreignObject>? |
| 04:04 | <Hixie> | with x=0 y=0 width=100% height=100%? |
| 04:04 | <Hixie> | that doesn't seem overly useful |
| 04:04 | <Hixie> | i'd just close the <svg> |
| 04:05 | <shepazu> | annevk: mind if I prettyprint it? |
| 04:05 | <annevk> | can table reparenting happen inside <svg>? |
| 04:05 | <annevk> | shepazu, no |
| 04:05 | <annevk> | as in, does <svg> create a slightly more sane parsing scope? |
| 04:08 | <Hixie> | annevk: ? |
| 04:10 | <annevk> | what happens for <svg> <table> <div> </div> </ table> </svg> |
| 04:10 | <Hixie> | shepazu: if you could elaborate on what you expect your error handling rules to be, that would be very useful |
| 04:10 | <Hixie> | it's not clear from the example |
| 04:11 | <Hixie> | annevk: i'd treat that the same as <svg> </svg (implied)><table> <div> </div> </table> </svg (ignored)> |
| 04:11 | <shepazu> | Hixie: I'm not sure yet, but I'll ponder it and read up on HTML5 more to get the true spirit of it |
| 04:11 | <annevk> | i see, that could work |
| 04:12 | <annevk> | what happens for <svg> <foreignobject> <table> <div> </div> </ table> <foreignobject> </svg> |
| 04:12 | <shepazu> | mind you, I'm just braindumping at this point |
| 04:12 | <Hixie> | annevk: (just checking, you mean </table>, rightL) |
| 04:12 | <Hixie> | ? |
| 04:12 | <annevk> | yes |
| 04:12 | <annevk> | oops |
| 04:13 | <shepazu> | and </foreignobject>? |
| 04:13 | <annevk> | also yes |
| 04:13 | <shepazu> | :) |
| 04:13 | <Hixie> | wait i'm confused |
| 04:13 | <Hixie> | paste again what you are talking about :-) |
| 04:13 | <Hixie> | without errors :-) |
| 04:13 | <shepazu> | lol |
| 04:13 | <annevk> | what happens for <svg> <foreignobject> <table> <div> </div> </table> </foreignobject> </svg> |
| 04:14 | <Hixie> | same as today, except the <svg> and <foreignobject> elements end up in the svg namespace |
| 04:14 | <Hixie> | and foreignobject becomes foreignObject |
| 04:15 | <shepazu> | my intuition is that it should be processed according to the rules for the overall document (unless there's a way to specify which mime type is meant....) |
| 04:15 | <annevk> | yeah, that's prolly fair enough |
| 04:15 | <annevk> | i was thinking of having sane error handling inside the new stuff, but there's no real argument for doing that |
| 04:16 | <shepazu> | could you do <html> <svg> <foreignobject> <html xmlns='...xhtml'> <div> </div> </html> </foreignobject> </svg> and have 2 different processing types for the html? |
| 04:16 | <Hixie> | we can't |
| 04:16 | <Hixie> | (that was to anne) |
| 04:16 | <shepazu> | right |
| 04:16 | <Hixie> | annevk: you could totally have that markup today, and we don't want to change the processing for it |
| 04:17 | <Hixie> | shepazu: again, that would likely break existing documents |
| 04:17 | <shepazu> | fair enough |
| 04:17 | <shepazu> | just thinking out loud |
| 04:17 | <Hixie> | even if it didn't break existing ones, it would break new UAs during the transition, because people would use the new syntax, but test it in old UAs, forget that the new syntax is present, assume (unknowingly) that it is ignored, and publish it |
| 04:18 | <Hixie> | so we'll end up with documents that use whatever new syntax we use, but that expect the legacy handling |
| 04:18 | <Hixie> | which, come to think of it, is an argument against there ever being a name for <ext> that won't have problems |
| 04:18 | <shepazu> | it's really edge anyway, I'm not concerned |
| 04:19 | <Hixie> | what is? |
| 04:19 | <shepazu> | my previous case |
| 04:19 | <Hixie> | ah |
| 04:19 | <shepazu> | still thinking about what you last said |
| 04:19 | <shepazu> | and watching tv |
| 04:20 | <shepazu> | sorry, what's the argument against <ext> (or whatever)? |
| 04:21 | annevk | added his <svg> as document element idea |
| 04:21 | <Hixie> | whatever syntax we end up using, people will copy and paste it from documents that were written by competent authors that tested it against the new UAs, into documents written by authors who don't know about this, and who don't have the new UA |
| 04:21 | <shepazu> | "(I being Anne.)" :) |
| 04:22 | <Hixie> | and those new documents will effectively be new legacy documents |
| 04:22 | <Hixie> | since they'll expect the legacy UA's processing |
| 04:22 | <shepazu> | Hixie: I'm not sure we will be able to avoid all pain with any part of HTML5, but that's debatable, I guess |
| 04:22 | <annevk> | the multiple UA thing is slightly less troublesome nowadays given that the "new UAs" have more market share |
| 04:22 | <shepazu> | I agree it's a noble goal, though |
| 04:22 | <Hixie> | i don't expect either firefox or IE to implement this first |
| 04:23 | <Hixie> | and the other UAs have very little market share |
| 04:23 | <shepazu> | no, Fx won't release for another 2 years, similar for IE |
| 04:24 | <Hixie> | annevk: your use case isn't one of those on the list of problems i'm trying to solve, fwiw :-) |
| 04:24 | <shepazu> | I expect first Opera or Safari, with the other following fast on the heels |
| 04:24 | <Hixie> | christ it's late |
| 04:24 | <Hixie> | i gotta go eat dinner |
| 04:24 | <Hixie> | bbl |
| 04:25 | <shepazu> | Hixie: but there might be an advantage in that, since implementors can play with it in the smaller browsers to get it right |
| 04:25 | <shepazu> | later |
| 04:25 | <shepazu> | thanks |
| 04:25 | shepazu | is tired, too :( |
| 04:30 | <annevk> | Hixie, hmm, good point, I added some rationale |
| 04:56 | <csarven> | Off topic: anyone recommend any books (any)? :) |
| 05:01 | <annevk> | The state of Africa from Marin Meredith |
| 05:01 | <annevk> | Martin* |
| 05:12 | <csarven> | Interesting |
| 06:58 | <Hixie> | christ there really are pages that use every element name under the sun |
| 06:59 | <Hixie> | this apge expects something that looks like TeX as children of <math> elements http://dark-legion.org/sl/Čas |
| 07:00 | <Hixie> | and this page says <FONT SIZE=+1><B>Влияние способа легирования кристаллов <MATH>n</MATH>-ZnSe медью на структуру центров свечения длинноволновой люминесценции |
| 07:00 | <Hixie> | http://www.ioffe.rssi.ru/journals/ftp/1998/02/page-171.html.ru |
| 07:00 | <Hixie> | no idea what they expect there |
| 07:01 | <Hixie> | anyway long and short of it is that we can't turn <math>(bogus content)</math> into <math><merror><mtext>(bogus content)</text></merror></math> |
| 07:01 | <Hixie> | or, for that matter, into <math><mi>(bogus content)</mi></math> as i was oproposing |
| 07:02 | <Hixie> | we can probably do <math><mtext>(bogus content)</mtext></math> |
| 07:03 | <Hixie> | ironically we can't even leave it as <math>(bogus content)</math> if we do use MathML, since the MathML rules would have that rendering an error inline |
| 07:03 | <annevk> | i don't really like those rendering rules |
| 07:04 | <Hixie> | i do |
| 07:04 | <Hixie> | :-) |
| 07:04 | <Hixie> | it's better than just ignoring the bogus stuff imho |
| 07:09 | <annevk> | hehe: http://www.google.com/virgle/index.html |
| 07:09 | <annevk> | looks like a shot from star wars or something |
| 07:13 | <annevk> | nn |
| 07:13 | <heycam> | http://www.google.com/virgle/plan_3.html reminds me of the game Output |
| 07:13 | <heycam> | er, Outpost |
| 07:31 | <BenMillard> | "Crew members will communicate with these machines via an auditory Holistic Artificial Language interface visually mediated by a glowing red light." |
| 08:02 | <hsivonen> | Hixie: what should I do with <mrow><none/><mprescripts/></mrow> and why? |
| 08:02 | <Hixie> | the dtd has two modes |
| 08:02 | <Hixie> | a "compatibility" mode, and a strict mode that actually matches the spec |
| 08:02 | <Hixie> | one checks for things like <mfrac> having two children, the other doesn't |
| 08:03 | <Hixie> | the relax stuff you provided implements the wrong one |
| 08:11 | <hsivonen> | I don't like leaving HTML+MathML+SVG integration to CDF. They've dragged their feet with "by-inclusion" long enough |
| 08:12 | <Hixie> | the great thing about cdf |
| 08:13 | <Hixie> | is that even if they decide that this _is_ their responsibility |
| 08:13 | <Hixie> | we'll be done and will have solved the problems long before they get their act together |
| 08:13 | <hsivonen> | I think <ext> is worse than a new insertion mode on <svg> and <math> |
| 08:16 | <Hixie> | http://www.thinkgeek.com/stuff/41/titaniumlabyrinth.html?cpg=70H is hilarious |
| 08:16 | <Hixie> | hsivonen: i agree, it has all the problems of a new insertion mode, and then some |
| 08:20 | <hsivonen> | Hixie: if you have Google data on <math> not being able to establish a scope for backwards compat, do you have data that the Web would break if <svg> had its own tree builder scope? |
| 08:23 | <Hixie> | i haven't looked at svg in much detail yet, only started looking today |
| 08:23 | <Hixie> | but what kind of problem could you envisage |
| 08:23 | <Hixie> | ? |
| 08:27 | <hsivonen> | Hixie: I don't expect the Web to break. I want an SVG insertion mode. |
| 08:27 | <Hixie> | the problems mentioned with mathml exist with svg too |
| 08:28 | <hsivonen> | does IE8 show the traits of having a tree builder scope for SVG and MathML? |
| 08:29 | <Hixie> | ? |
| 08:30 | <Hixie> | i have some more concrete numbers for mathml now |
| 08:30 | <Hixie> | out of about 3/4 of a billion documents: |
| 08:30 | <hsivonen> | Hixie: does IE8 already break you compat assumptions (if xmlns is present)? |
| 08:30 | <Hixie> | ~50000 had a <math> or <foo:math> element |
| 08:31 | <Hixie> | ~40000 had <math> and only presentational mathml elements, no content mathml, no <semantic>, no <annotation-xml> |
| 08:32 | <Hixie> | ~800 seemed to have only content mathml |
| 08:32 | <Hixie> | ~500 seemed to have both |
| 08:32 | <Hixie> | ~900 seemed to have <semantics> or <annotation-xml> elements |
| 08:32 | <Hixie> | ~10000 had <math> elements but didn't seem to have any other mathml elements |
| 08:33 | <hsivonen> | Hixie: If you a couple at random and load them in Firefox, do you get a different content type from what google saw? |
| 08:33 | <hsivonen> | If you take a couple... |
| 08:33 | <virtuelv> | did anyone find out what the <hype> element did? |
| 08:34 | <Hixie> | i screwed up the sampling for content mathml and pres+content mathml, so i can't give reliable urls for those two |
| 08:35 | <hsivonen> | I didn't find out, but it sounds like it could be to <blink> what <em> is to <i> :-) |
| 08:36 | <Hixie> | interesting, most of the presentational mathml pages seem to from freepatentsonline |
| 08:37 | <Hixie> | http://www.hindawi.com/GetArticle.aspx?doi=10.1080/15604280212526&e=cta is another example |
| 08:38 | <Hixie> | a strikingly worthless use of mathml if ever there was one... |
| 08:39 | <Hixie> | http://www.emis.de/journals/HOA/JIA/2d12.html?doi=10.1155/JIA/2006/15063 is text/html |
| 08:39 | <Hixie> | even in firefox |
| 08:39 | <Hixie> | and contains mathml with prefixes |
| 08:41 | <Hixie> | hsivonen: checking IE8... |
| 09:02 | <hsivonen> | “Given that HTML5 is intended to be a replacement/evolution of HTML |
| 09:02 | <hsivonen> | in an era when the semantic web is coming of age” :-) |
| 09:23 | <sayrer> | an XML notation for CSS |
| 09:23 | <sayrer> | hmm |
| 09:23 | <sayrer> | is this a time wasting tactic of some sort? |
| 09:24 | <sayrer> | gah |
| 09:24 | <sayrer> | this is the 5th April 1st joke I have fallen for |
| 09:24 | <sayrer> | I think I will try to avoid the computer tomorrow |
| 09:25 | <sayrer> | funny that one didn't seem so far-fetched |
| 09:26 | <hsivonen> | I'm worried about the CSS versioning suggestion, though |
| 09:26 | <hsivonen> | Levels are Good for Web formats |
| 09:27 | <sayrer> | I try to avoid reading the CSS WG list |
| 09:28 | <sayrer> | I don't know much about CSS for someone who works on browsers, and that list seems highly gamed |
| 09:29 | <virtuelv> | sayrer: it's not really that far-fetched |
| 09:29 | <virtuelv> | see Joe English' proposal, http://virtuelvis.com/archives/2005/01/css-history |
| 09:30 | <hsivonen> | well, XSL-FO is basically Jukka Korpela's April Fools joke from a few years ago... |
| 09:31 | <hsivonen> | http://www.cs.tut.fi/~jkorpela/html/xhtml3.html |
| 09:32 | <sayrer> | hmm, wonder what the April 1st RFCs are this year |
| 09:33 | <sayrer> | it will be difficult to best RFC 3252 |
| 09:35 | <sayrer> | hmm, looked under most recent RFCs |
| 09:35 | <sayrer> | evidently RFC 5168 is from March |
| 10:35 | <Lachy> | it's always nice to see people quote mining. http://html4all.org/mailman/archives/list_html4all.org/2008-April/000676.html |
| 10:36 | <Lachy> | I really wonder what his intent is with pulling out statements like that, instead of responding directly with a counter argument. |
| 10:45 | <kfish> | Lachy, perhaps that mode of disagreement falls somewhere between levels 2 and 3 in http://paulgraham.com/disagree.html |
| 10:48 | <hendry> | what's the form input switch between numbers and alpha characters defined as nowadays? |
| 10:48 | hendry | has forgotten |
| 10:49 | <hendry> | i think in WF2 it's pattern="[0-9" though i wasn't there something else |
| 10:52 | <hendry> | inputmode? http://www.whatwg.org/specs/web-forms/current-work/#inputmode however the link there is http://www.w3.org/TR/xforms/sliceE.html is a 404 |
| 10:58 | <Dashiva> | Lachy: Maybe they wanted to raise the quality level of the posting, so they went to Hixie for content ;) |
| 11:29 | <virtuelv> | no blog post today? |
| 11:31 | <Lachy> | virtuelv, on which blog? |
| 11:31 | <Lachy> | the whatwg blog? feel free to write one |
| 11:32 | <virtuelv> | nono, I've blogged once today already |
| 11:34 | gsnedders | still has no idea what to do in the next twenty minutes |
| 11:40 | <Dashiva> | gsnedders: Write an excellent whatwg blog post |
| 11:40 | <gsnedders> | Dashiva: My mind is void of ideas, though |
| 11:42 | <Dashiva> | virtuelv: I wasn't aware that youtube hosted opera's press releases. I thought we were against using proprietary video ;) |
| 11:43 | <gsnedders> | Double-standards! Opera are worthless! |
| 11:43 | <gsnedders> | Scub! |
| 11:45 | <Dashiva> | Are you pro or anti? |
| 11:45 | <gsnedders> | I'm not a pro, I'm just an amateur |
| 11:46 | <Dashiva> | You could write a post saying HTML5 is now defining scub a MUST NOT requirement |
| 11:46 | <gsnedders> | Dashiva: not overly funny, though |
| 11:47 | <Dashiva> | Of course not, that's just a seed idea. You have to plant and nourish it so it'll bloom into excellence :) |
| 11:47 | <Lachy> | what is "scub"? |
| 11:47 | <gsnedders> | scum spelt wrong |
| 11:48 | <Dashiva> | No, no |
| 11:48 | <gsnedders> | scub is… http://www.urbandictionary.com/define.php?term=Scub |
| 11:48 | <gsnedders> | I wobn't say here |
| 11:48 | <gsnedders> | Well, there's more than one meaning |
| 11:49 | <gsnedders> | But I meant scum, I just spelt it wrong :P |
| 11:49 | <Dashiva> | There's also http://pbfcomics.com/?cid=PBF020-Skub.gif |
| 11:57 | <gsnedders> | HTML 5 is so pointless. We should just be moving to XHTML 5. |
| 11:59 | <Dashiva> | You aren't even trying :/ |
| 12:00 | <gsnedders> | I mean, with XML 5! |
| 12:01 | <Dashiva> | How about getting Hixie to resign as editor. That might work :) |
| 12:01 | <Lachy> | gsnedders, april fools day articles need to be about something funny that is unlikely to ever happen. XML 5 is very likely to happen one day |
| 12:02 | <gsnedders> | Lachy: I know :P |
| 12:02 | <Lachy> | Dashiva, IIRC, Hixie said no to that one last year |
| 12:03 | <gsnedders> | Lachy: last year on my blog: me getting a gf. Anyone who knows me well enough on IM, or how I acted in some IRC channels then, would find that totally implausible |
| 12:03 | <Lachy> | though, I could be wrong. But I'm fairly sure it was thought of and there was some reason not to go for it |
| 12:03 | <Dashiva> | We could try Hyatt, but who even knows he's also an editor |
| 12:03 | <gsnedders> | I do!!1111!!1eleventy! |
| 12:04 | <Lachy> | anyone know if the IETF will actually be publishing an RFC today? |
| 12:05 | <gsnedders> | They didn't in 2007, did they? |
| 12:05 | <gsnedders> | I dunno. I've not been in contact with the RFC editor for a while |
| 12:05 | <Lachy> | yeah, last year was the semaphore flag signalling thing |
| 12:05 | <Lachy> | http://tools.ietf.org/html/rfc4824 |
| 12:05 | <gsnedders> | ah. I forgot that one. |
| 12:05 | <gsnedders> | Bert was the year before, then? |
| 12:06 | <gsnedders> | Yeah, he was |
| 12:06 | <Lachy> | yes, 2006 |
| 12:06 | <Lachy> | http://en.wikipedia.org/wiki/April_Fools%27_Day_RFC |
| 12:15 | gsnedders | wonders whether to try to implement UTF-9 in an 8-bit language |
| 12:25 | <zcorpan> | so who's gonna write something on the whatwg blog? |
| 12:29 | <Lachy> | zcorpan, I will if someone comes up with a good topic |
| 12:30 | <Lachy> | everything I think of is just not funny enough |
| 12:31 | <zcorpan> | there was some discussion yesterday |
| 12:33 | <Lachy> | aargh! blog.whatwg.org has internal server errors |
| 12:33 | <Lachy> | hmm. weird, it fixed after a reload |
| 12:50 | gsnedders | really can't think of anything funny |
| 12:53 | <tomg> | http://my.opera.com/desktopteam/blog/2008/04/01/acid-3-opera-first-to-106 |
| 12:55 | gsnedders | blames Hixie |
| 12:55 | <Dashiva> | I'm not convinced, really. Six points for changing each block into an egg, but there should be a seventh point for making one of the eggs hatch! |
| 12:58 | <gsnedders> | anyone know anyway to do URL normalisation in Python? |
| 13:05 | <Lachy> | we should just introduce a bug that causes Acid3 to enter an infinite loop, and then we can claim to the first browser to reach infinity |
| 13:06 | <Philip`> | Lachy: But an infinite loop will only ever have reached a finite number of repetitions... |
| 13:07 | <Lachy> | Philip`, not if we leave the build running for eternity |
| 13:07 | <zcorpan> | Hixie: can the test be changed to the easter egg version? :P |
| 13:08 | <Dashiva> | zcorpan: Sure, if you reveal the triggers :) |
| 13:08 | <Lachy> | maybe we could publish a UserJS that does it, like Opera did for Acid2 with the eyes |
| 13:09 | <zcorpan> | acid2 with the eyes? |
| 13:10 | <Lachy> | there was a build of Opera (and subsequent UserJS) released that caused the eyes to begin following the mouse after about a minute |
| 13:11 | <Lachy> | http://en.wikipedia.org/wiki/Features_of_the_Opera_web_browser#Opera_9_Acid2_easter_egg |
| 13:13 | <zcorpan> | lol |
| 13:43 | <gsnedders> | Walking up stairs in walking boots is hard. |
| 14:35 | <hendry> | for same origin type security and offline resources file URLs like "file:///db" considered to be "domains"? |
| 14:40 | <hendry> | annevk: you might be able to help me :) |
| 14:40 | <annevk> | ok... |
| 14:40 | <hendry> | annevk: for same origin type security and offline resources file URLs like "file:///db" considered to be "domains"? |
| 14:41 | <annevk> | ooh, that differs per browser |
| 14:41 | <annevk> | not standardized as it doesn't affect interop |
| 14:41 | <hendry> | using something like "file:///db" for implementing offline support, is that OK? |
| 14:42 | <hendry> | I see Gears see to do stuff with a localhost type domain service IIRC |
| 14:42 | <virtuelv> | I find it troubling that only one of the april fool's RFCs has been implemented |
| 14:51 | <Lachy> | virtuelv, I think 2 have been implemented |
| 14:51 | <Lachy> | RFC 1149 (as mentioned in that wikipedia article) and the evil bit |
| 14:53 | <Lachy> | and UTF-9/UTF-18 were implemented in PDP-10 assembly language apparently |
| 14:53 | <Lachy> | http://en.wikipedia.org/wiki/UTF-9_and_UTF-18 |
| 15:13 | <zcorpan> | Hixie: the login box overlaps the text in the spec |
| 15:15 | <virtuelv> | Lachy: I knew about 1149, but UTF-9 came as a surprise |
| 15:16 | <zcorpan> | Hixie: also, it's not at the top of the spec when css is disabled :P |
| 15:19 | <Lachy> | ha! http://uk.youtube.com/ - every featured video is Rickroll :-) |
| 15:20 | <zcorpan> | hmm that url crashed merlin |
| 15:43 | <hsivonen> | Hixie: despite the claimed duality anti-pattern, I feel like saying +1 to what Neil Soiffer says about putting Content MathML in the DOM |
| 15:50 | <zcorpan> | hsivonen: pointer? |
| 15:51 | <hsivonen> | zcorpan: http://lists.w3.org/Archives/Public/public-html/2008Apr/0016.html |
| 16:17 | <zcorpan> | firefox doesn't the "invalid markup" for <math xmlns=...>foobar</math> |
| 16:17 | <zcorpan> | Hixie: ^ |
| 16:17 | <zcorpan> | so no need to imply <mtext> |
| 16:17 | <zcorpan> | s//render/ |
| 16:18 | <zcorpan> | data:text/xml,<math xmlns='http://www.w3.org/1998/Math/MathML'><mfrac>foo</mfrac></math>; |
| 16:18 | <zcorpan> | data:text/xml,<math xmlns='http://www.w3.org/1998/Math/MathML'>foo</math>; |
| 16:45 | <annevk> | hsivonen, I don't think the poisening is deliberate |
| 16:46 | <annevk> | hsivonen, as was already noted, doing generic parsing may not be feasible given deployed content |
| 16:50 | <hsivonen> | annevk: if there's a hard-coded list, putting additional entries on the list doesn't seem like a big deal |
| 16:52 | <annevk> | and what are the use cases if it isn't HTML anymore and very hard for the user to get to as it is never displayed? |
| 16:53 | <annevk> | s/HTML/XML/ |
| 16:56 | <hsivonen> | annevk: the use case is math course material with vendor-independent excercise material |
| 16:56 | <hsivonen> | s/excercise/exercise/ |
| 17:01 | <annevk> | how is MathML itself not vendor-independent? |
| 17:34 | <hsivonen> | annevk: Presentation MathML alone doesn't everything you'd want to round-trip from a computer algebra package via the Web back to a computer algebra package (possibly from a different vendor) |
| 17:39 | <annevk> | that's true for HTML, CSS, etc. too |
| 17:50 | <hsivonen> | annevk: what's true? that HTML and CSS aren't rich enough to round-trip to computer algebra packages? |
| 18:03 | <annevk> | oh, maybe I missed your point |
| 18:56 | <andersca> | Hixie? |
| 19:15 | <annevk> | looking at http://wiki.whatwg.org/wiki/Diagrams_in_HTML it seems that while <ext> might be more "pure" (for some value) the first proposal is far easier to author |
| 21:39 | gsnedders | yawns |
| 21:45 | <Hixie> | hsivonen: while adding the occasionaly element to a hard coded list is one thing, adding _140_ elements that in practicve are goign to be used in (number forthcoming)% of web pages, is just silly |
| 21:46 | <hsivonen> | Hixie: depends on the actual perf hit with binary search or a more clever mechanism (e.g. switch by length first) |
| 21:47 | <hsivonen> | With interned strings, the memore footprint increase should be around 140 * pointer size |
| 21:48 | <Hixie> | it really doesn't depend on anything |
| 21:48 | <Hixie> | it's over 140 elements! |
| 21:49 | <hsivonen> | says an editor who has spec bit involving checking the Unicode class of syntax-significant characters :-) |
| 21:50 | <hsivonen> | how is containment lookup from a set of 140 strings different from lookups from Unicode classes? |
| 21:52 | <Hixie> | i immediately rejected the idea of testing unicode character classes when you pointed out the problem with that, btw |
| 21:52 | <Hixie> | i am mildly embarassed that i forgot our goal :-) |
| 21:53 | <hsivonen> | Hixie: it's still on the above-DOM level in <time> element contents and <progress> contents, IIRC |
| 21:53 | <Hixie> | yeah, dunno what we'll do about those. i'm sure you've sent feedback. |
| 21:53 | <Hixie> | still, that's not as serious as in the parser |
| 21:54 | hsivonen | notes that XML requires crazy checking for the Name production. in the parser |
| 21:55 | <Hixie> | oh actually i guess we do have that kind of checking in html5 too |
| 21:55 | <Hixie> | in some places |
| 21:56 | <hsivonen> | I think I have it only when the user of the parser has requested that XML violations not be passed through |
| 22:05 | gsnedders | is implementing UTF-9 in an octet-based language |
| 22:07 | <Philip`> | gsnedders: The first step should be to write an emulator for a 9-bit CPU architecture, and then the rest is straightforward |
| 22:07 | <gsnedders> | Philip`: But that takes out half the fun :P |
| 22:07 | <gsnedders> | Actually, it wouldn't |
| 22:07 | <gsnedders> | You just have the fun in the emulator |
| 22:07 | <Philip`> | gsnedders: Then make it 18-bit and you'll get that half back again |
| 22:08 | <Philip`> | You could base it on the EDSAC |
| 22:12 | <gsnedders> | Philip`: basically, I'm converting everything to nonets then doing all the hard work |
| 22:31 | Hixie | grins evilly |
| 22:31 | <Hixie> | we could make the φ entity resolve to different things in a mathml context than an html one... |
| 22:31 | <gsnedders> | Hixie: Oh piss off :P |
| 22:31 | <gsnedders> | Needless complexity ftl. |
| 22:32 | <Dashiva> | How long has φ been in MathML and HTML respectively? |
| 22:33 | <hsivonen> | Dashiva: Unicode changed underneath both... |
| 22:33 | hsivonen | blames Unicode Consortium for giving into pressure from national interest groups |
| 22:33 | <Dashiva> | So, how 'bout them capital double s glyphs |
| 22:34 | <hsivonen> | case mappings for those will be a mess... |
| 23:22 | <Hixie> | btw, for whoever it was who was asking about how the proposal that involved xmlns="" attributes would work in IE8, i haven't been able to get IE8 to do anything like what microsoft says it does |
| 23:23 | Philip` | hasn't either |
| 23:23 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/ie8.html - paste in some mathml, the DOM doesn't look anything like it was handled by xml |
| 23:23 | <Hixie> | so i think it's a non-isse |
| 23:24 | <Hixie> | anyway. bll |
| 23:24 | <Hixie> | bbl too. |
| 23:24 | <Philip`> | Sounds like it's a feature that just didn't make it into beta 1 |
