| 00:12 | <Hixie> | hsivonen: would it make sense to have a schema for the mathml part of mathml+html5, as opposed to just saying it has to match the mathml spec? |
| 00:12 | <Hixie> | or would it be better to just let the syntax make certain things impossible, but not disallow them |
| 00:21 | <jgraham> | othermaciej: Sent. |
| 00:23 | jgraham | wonders how many other specs he can complain about the lack RFC 2119 terminology in |
| 00:23 | <jgraham> | (I did aria earlier in the week) |
| 00:24 | <Hixie> | http://wiki.whatwg.org/wiki/Equations_in_HTML really makes a strong case for making <mo>/<mi>/<mn> be inferred by the parser |
| 00:26 | <jgraham> | I wonder what fraction of the time people miss out ⁢ when hand authoring |
| 00:37 | <jgraham> | Hixie: How would the <msup> stuff work? What would <msup> (x + 3) 2</msup> do? |
| 00:51 | <Hixie> | show an error |
| 01:52 | <Hixie> | msup needs two children |
| 01:52 | <Hixie> | <msup>x 2</msup> would work |
| 01:52 | <Hixie> | <msup><mrow>(x+3)</mrow>2</msup> would work |
| 01:52 | <Hixie> | (not sure what the right thing to do is with the brackets) |
| 01:52 | <jgraham> | Right but authors will expect <msup>(x + 2) 2</msup> to work |
| 01:53 | <jgraham> | If <msup>x 2</msup> works |
| 01:55 | jgraham | -> sleep |
| 02:22 | <Hixie> | jgraham__: authors expect a lot of things to work. they get over it when it doesn't. :-) |
| 02:24 | <Pavlov> | Hixie: what happens if you have implied <mi> and then add a <mi> element? |
| 02:24 | <Pavlov> | or just change mi? |
| 02:25 | <Pavlov> | or change msup |
| 02:25 | <Pavlov> | (i can imagine several different things, all of which are pretty confusing) |
| 02:27 | <Hixie> | how do you mean? |
| 02:28 | <Pavlov> | like in your example http://wiki.whatwg.org/wiki/Equations_in_HTML |
| 02:28 | <Pavlov> | if i add a <mo> element to the first mrow from script, what happens? |
| 02:29 | <Hixie> | you mean like you change the markup to <math> x <mo>=</mo> <mfrac> ... ? |
| 02:29 | <Hixie> | it wouldn't make any difference, the markup is equivalent |
| 02:29 | <Pavlov> | say you start with <math>x =</math> |
| 02:30 | <Hixie> | oh you mean through DOM manipulation? |
| 02:30 | <Pavlov> | right |
| 02:30 | <Hixie> | the elements would all be there in the DOM all the time |
| 02:30 | <Hixie> | the parser would insert them |
| 02:30 | <Hixie> | like it does with tbody in tables |
| 02:30 | <Hixie> | if that's not what you meant, i'll reply when i get back from dinner |
| 02:30 | <Hixie> | gotta go |
| 02:30 | <Pavlov> | thats weird though isn't it? |
| 02:31 | <othermaciej> | implied elements are weird |
| 02:45 | <shepazu> | implied elements make script authors do a lot more work |
| 02:45 | <Dashiva> | You mean less |
| 02:45 | <shepazu> | no... |
| 02:46 | <Dashiva> | Implied elements mean we don't have to check if there's actually a tbody present. Then XHTML comes along and ruins it |
| 02:46 | <shepazu> | when I author a document, I expect the markup to be represented in the DOM just as I wrote the markup |
| 02:47 | <shepazu> | if I could rely on that, I wouldn't have to do screwy tests to find out what the DOM thinks the markup should be |
| 02:47 | <shepazu> | so the author ends up having to do extra tests |
| 02:47 | <Dashiva> | Implied elements are predictable |
| 02:48 | <shepazu> | to expert authors, probably so |
| 02:48 | <shepazu> | but most authors are not expert |
| 02:49 | <shepazu> | I prefer wysiwyg DOM parsing |
| 02:50 | <Philip`> | Hypothesis: Most authors wouldn't predict <tbody> |
| 02:50 | <Dashiva> | Hypothesis: Most authors either use .tBodies[0] because they were told to, or use getElementsByTagName('tr') and don't care about the tbody |
| 02:50 | <shepazu> | I suspect most authors don't even know <tbody> exists |
| 02:51 | <Philip`> | Everybody always includes <html> and <head> and <body> even though those could easily be omitted and implied |
| 02:52 | <Philip`> | so it seems people don't understand the concept of implied elements to an extent that they intentionally make use of it |
| 02:52 | <shepazu> | I say, the less voodoo the better |
| 02:53 | <Dashiva> | shepazu: Well, have fun with your documentElement when <html> is implied |
| 02:54 | <shepazu> | why would I not include an <html> element? |
| 02:54 | <shepazu> | I would expect and hope for an error if I tried to do that |
| 02:54 | <shepazu> | (use documentElement if I didn't have an <html> element) |
| 02:54 | <Dashiva> | HTML is big on silent error recovery |
| 02:55 | <shepazu> | yes, I think I heard someone mention that in passing |
| 02:55 | <shepazu> | but I didn't take them seriously |
| 02:57 | <shepazu> | I don't mind silent error recovery when I'm browsing |
| 02:57 | <shepazu> | but I want to be able to serve the best possible content for my readers/users |
| 02:58 | <deane> | I think there's a strong case to keep the differences between html and xhtml to a minimum. Which means that I think SVG and MathML markup should be the same in html5 and xhtml5 |
| 02:59 | <deane> | They could be the same right? |
| 02:59 | <shepazu> | well, obviously you'll get no argument from me there, but I wasn't talking about SVG (for once) |
| 02:59 | <Dashiva> | There's nothing preventing you from making implicit elements explicit |
| 03:00 | <deane> | But it's not me that I'm worried about |
| 03:00 | <deane> | other authors will be confused between two syntaxes |
| 03:01 | <markp> | that would certainly make sam happy |
| 03:01 | <markp> | (reducing differences) |
| 03:02 | <deane> | ... otherwise we end up with bits of SVG and MathML that only work in text/html |
| 03:02 | <Dashiva> | I would expect that anyone able to understand mathml well enough to write it by hand would not be confused |
| 03:02 | <markp> | afaik, there's only one person who does that |
| 03:02 | <markp> | in the whole web |
| 03:03 | <shepazu> | Dashiva, I would argue that anyone that writes mathml by hand is confused ;) |
| 03:03 | <shepazu> | (says the guy that draws SVG content in a text editor) |
| 03:03 | <Dashiva> | That, too, is true |
| 03:04 | <markp> | sam draws svg in vi |
| 03:04 | <shepazu> | ugh. |
| 03:04 | <markp> | he's quite good at it |
| 03:04 | <shepazu> | I used TextPad or TextMate |
| 03:04 | <markp> | to each his own |
| 03:04 | <shepazu> | yup |
| 03:06 | <shepazu> | honestly, I think that there's a serious case for being able to tweak document structure that makes using a text editor to make or massage SVG rather reasonable, though it's not for everyone |
| 03:07 | <shepazu> | just kidding about MathML, of course... the only times I've used MathML I did it by hand, of course |
| 04:50 | <Hixie> | i don't think optimising text/html syntax for compatibility with xhtml makes any sense |
| 06:17 | <heyadayo> | hello |
| 06:18 | <heyadayo> | I'm implementing a close approximation of the html5 TCPConnection for current/older browsers, and I had some questions |
| 06:19 | <heyadayo> | Do any browsers currently implement the html5 EventListener? |
| 08:19 | <hsivonen> | jgraham__: I think the proper way for Mathematica to encode a superset of information would be to make sure Content MathML is rich enough to represent the superset in a cross-product way |
| 08:22 | <hsivonen> | Hixie: I'd prefer to have DOM consistency between HTML5+MathML and XHTML5+MathML-as-defined-by-its-own-WG |
| 08:22 | <hsivonen> | Hixie: if MathML has something bad, I'd prefer to get MathML 3 changed instead of HTML WG shunning parts of it |
| 08:27 | <hsivonen> | http://academia.hixie.ch/physics/2dfsurvey/report/report.xml looks terrible in Firefox 3.0b4 on Mac |
| 08:28 | <gavin> | what parts look terrible? |
| 08:30 | <gavin> | seems to be ok for me |
| 08:30 | <gavin> | but I'm not sure if I'm not seeing the ugliness because I don't know what to expect and am just not noticing it, or because I don't have the right fonts, or because my build is newer than yours, or because I'm on Windows |
| 09:02 | <roc> | I can see a few things that could be improved, but I wouldn't say it looks terrible |
| 09:02 | <roc> | on trunk anyway ... there are a few table improvements post-b4 |
| 09:24 | <[malfi]> | hi all |
| 09:26 | <hsivonen> | gavin: the formulas that stand on their own on a line spread to the whole view port width |
| 09:28 | <gavin> | hsivonen: http://people.mozilla.org/~gavin/mathml.png is what I see |
| 09:29 | <gavin> | (latest trunk nightly on windows) |
| 09:29 | <gavin> | I would be interested in knowing whether a more recent build fixes the problems you're seeing |
| 09:50 | <hsivonen> | gavin: much better than b4 on Mac |
| 09:51 | <Hixie> | hsivonen: yes, i completely agree, i was only considering conformance requirements that were a subset of the mathml spec |
| 10:06 | <Hixie> | i wonder if there are ever times in mathml where <mi> and/or <mn> elements are siblings without an intervening <mo> element |
| 10:12 | <hsivonen> | Hixie: but why bother with all the inference if the result is still ugly enough that people will use converters from *TeX, Mathematica, etc. or a GUI editor? |
| 10:29 | <Hixie> | http://wiki.whatwg.org/wiki/Equations_in_HTML |
| 10:29 | <Hixie> | it's not that bad after just removing mn, mo, and mi |
| 10:29 | <Hixie> | and that's, as far as i can tell, a trivial optimisation in most cases |
| 10:29 | <Hixie> | since it only affects markup that cannot otherwise be valid |
| 10:31 | <Hixie> | seems like we could make Nd, Nl, and No trigger <mn>, Pc, Pd, Po, Sm, Sk, and So trigger <mo>, and Lu, Ll, Lt, Lm, Lo, and Sc trigger <mi> |
| 10:32 | <Hixie> | and maybe do something clever with fences for Ps, Pe, Pi, and Pf |
| 10:32 | <Hixie> | (i haven't looked at this in detail yet) |
| 10:32 | <Hixie> | but fundamentally, even if we limit this to ascii, it's still going to be a big step forward. |
| 10:38 | <hsivonen> | Hixie: lookups from the Unicode DB would break the current property of the parsing algorithm of keeping all syntax-significant characters in the Basic Latin range |
| 10:38 | <hsivonen> | (so the current spec allow per-code unit parsing in all of UTF-8, UTF-16 and UTF-32) |
| 10:39 | <Hixie> | true |
| 10:39 | <hsivonen> | (once the stream is guaranteed to be valid UTF-8, UTF-16 or UTF-32 by the encoding layer) |
| 10:39 | <Hixie> | but like i said, we could even limit it to ascii |
| 10:39 | <Hixie> | it would still be hugely helpful |
| 10:39 | <Hixie> | (especially since once people get outside ascii, it's increasingly unlikely that the markup is hand-maintainable anyway |
| 10:40 | <Hixie> | ) |
| 10:40 | <Hixie> | incidentally, i don't see any way to get the math guys to abandon the folly of wanting multiple representations of a single equation in the markup, which is another point against going the mathml route |
| 10:41 | <hsivonen> | ⁢ is a crazy number of characters to type by hand for something can turns into glyphlessness |
| 10:41 | <Hixie> | yes earlier i was looking at how to imply <mo>⁢</mo> |
| 10:42 | <Hixie> | <Hixie> i wonder if there are ever times in mathml where <mi> and/or <mn> elements are siblings without an intervening <mo> element |
| 10:43 | <hsivonen> | fwiw, tag inference in HTML 4 has already been a pain for HTML5 |
| 10:44 | <hsivonen> | wouldn't tag inference in MathML 3 be a pain fo MathML 4? |
| 10:53 | <Hixie> | why has it been a pain in HTML5? |
| 10:53 | <Hixie> | tag inference is one of the main features of html that makes it usable from an authoring perspective, imho |
| 11:00 | <hsivonen> | Hixie: we can't allow <ul> in <p> |
| 11:01 | <hsivonen> | Hixie: we can't allow <table> in <p> post-Acid2 |
| 11:01 | <hsivonen> | there are probably other features involving <p> that I'm not even thinking about because of the end tag inference |
| 11:03 | <roc> | where is this math-in-HTML discussion happening? public-html? |
| 11:04 | <hsivonen> | roc: mostly public-html with some messages from William Hammond on www-math only |
| 11:06 | <Hixie> | hsivonen: i think those might actually be good things, frankly. but yes, it does constrain future language development. |
| 11:06 | <Hixie> | i think that's an acceptable cost |
| 11:06 | <Hixie> | anyway, bed time |
| 11:06 | <Hixie> | if you find a way to convince them to not require html5 to support both presentational and content mathml, let me know :-) |
| 11:08 | <roc> | is it at least settled that any solution would construct a MathML DOM for rendering? |
| 11:09 | <roc> | gavin: your screenshot actually looks pretty bad to me, my Mac build looks much better because the curly braces stretch |
| 11:09 | <roc> | you probably just don't have the right fonts |
| 11:12 | <hsivonen> | what's mozilla-central? |
| 11:12 | <roc> | a Mercurial code repository that you probably shouldn't be interested in |
| 11:13 | <hsivonen> | roc: thanks. I download from latest-trunk then |
| 11:13 | <roc> | yeah |
| 11:15 | <roc> | the problems I saw on that page were 1) stretchy braces have slight thickness variations along the stem (known antialiasing bug) 2) some table columns sized a bit too wide 3) primes ( ' ) maybe positioned a little high |
| 11:18 | <hsivonen> | http://hsivonen.iki.fi/screen/mathml-firefox3b4.png |
| 11:31 | <hsivonen> | http://hsivonen.iki.fi/screen/mathml-minefield-2008-03-29.png |
| 11:31 | <hsivonen> | much better |
| 11:58 | <roc_> | hsivonen: er yoicks, I had no idea beta4 was that broken |
| 16:05 | annevk | reads the Math thread |
| 16:05 | annevk | kind of likes the idea of characters implying elements |
| 16:14 | <hsivonen> | ttp://realtech.burningbird.net/standards/acid3-and-my-head-hurts/ |
| 16:16 | <annevk> | I don't really understand that post |
| 16:28 | <hsivonen> | I read it as "don't fix browser bugs when my book is going to press" |
| 16:30 | <annevk> | lol |
| 16:35 | <Dashiva> | What kind of proofs, though? |
| 16:36 | <Dashiva> | And who writes a book about beta-version browers anyhow |
| 16:36 | <hsivonen> | Dashiva: proofs of the proof-print kind, I suppose |
| 17:13 | <roc> | I think that post is probably complaining about features being enabled on trunk builds with no clear roadmap to them actually being shipped |
| 17:16 | <annevk> | oh |
| 17:16 | <hsivonen> | ok. that wasn't too clear |
| 17:16 | <annevk> | well, in case of Opera it will ship post-Kestrel unless we find some way to make it work for Kestrel, but I doubt that |
| 17:16 | <annevk> | that's not really a secret |
| 17:17 | <annevk> | (Kestrel is near ready, much like Firefox 3) |
| 17:17 | <hsivonen> | roadmap-wise, I'd be interested in XHR+AC roadmap post Firefox 3 |
| 18:57 | <othermaciej_> | Safari/WebKit has never given a roadmap to shipping for anything |
| 18:57 | <othermaciej_> | and we've been known to disable trunk features on release branches |
| 18:57 | <othermaciej_> | so |
| 18:57 | <othermaciej_> | I don't think Acid3 can be blamed |
| 19:06 | <gsnedders> | It's Acid3's fault. kthxbai. |
| 19:14 | <othermaciej> | we're obviously not going to ship Acid3 fixes in Safari 3.1, since it has already shipped |
| 19:23 | <gsnedders> | WHAT!? |
| 19:23 | <gsnedders> | You're kidding, right? |
| 19:25 | <sayrer> | what is the smallest SVG spec? |
| 19:25 | <othermaciej> | that's right, we can't go back in time |
| 19:25 | <shepazu> | sayrer: probably the VML note that MS proposed is the smallest SVG spec :) |
| 19:26 | <sayrer> | shepazu, seriously, what's the smallest? |
| 19:26 | <shepazu> | I honestly don't know, but I'd have to guess SVG 1.0 |
| 19:27 | <shepazu> | that said, I think SVG Tiny 1.2 is much more clean and well-defined |
| 19:27 | <sayrer> | I should clarify--I meant number of features, rather than spec length |
| 19:27 | <shepazu> | and though it has features some people don't like, is a better implementation target |
| 19:27 | <sayrer> | a long spec detailing a small number features would be best |
| 19:27 | hsivonen | guesses 1.1 Tiny/Mobile |
| 19:27 | <shepazu> | oh, then probably SVG Tiny 1.2 |
| 19:28 | <shepazu> | oops |
| 19:28 | <shepazu> | SVG Tiny 1.1 |
| 19:28 | <shepazu> | but that doesn't have scripting support, so most browsers already pass that by |
| 19:28 | <hsivonen> | sayrer: why? |
| 19:29 | <othermaciej> | each version of SVG has somewhat incompatibly changed the semantics (mostly minor) |
| 19:29 | <sayrer> | I want to use SVG for a purpose that doesn't have many requirements |
| 19:29 | <othermaciej> | for instance 1.1 technically requires you to catastrophically fail at rendering any time any attribute value is invalid |
| 19:29 | <sayrer> | just simple drawings |
| 19:29 | <shepazu> | then SVG Tiny 1.1 |
| 19:30 | <sayrer> | hmm, it has animation |
| 19:30 | <shepazu> | true |
| 19:30 | <sayrer> | guess I have to make SVG 1.1 ReallyTiny |
| 19:30 | <shepazu> | lol |
| 19:30 | <sayrer> | interactivity is not required either |
| 19:31 | <othermaciej> | I don't think there is an SVG spec that is only suitable for simple drawings and no more |
| 19:31 | <shepazu> | then you can simply do a profile of SVG |
| 19:31 | <othermaciej> | some are more out of control than others |
| 19:31 | <shepazu> | there's an appendix that describes various profiles, including static |
| 19:31 | <sayrer> | oh good |
| 19:31 | <shepazu> | lemme find it |
| 19:32 | <shepazu> | http://www.w3.org/TR/SVG11/feature.html |
| 19:33 | <shepazu> | see http://www.w3.org/TR/SVG11/feature#SVG-static |
| 19:33 | <sayrer> | hmm, still has xlink |
| 19:33 | <sayrer> | I don't need links |
| 19:34 | <shepazu> | that's also used for inbound links, like image references |
| 19:34 | <sayrer> | well, I only want to allow data URLs for those |
| 19:34 | <sayrer> | do I have to use xlink to get that? |
| 19:35 | <sayrer> | lordy |
| 19:35 | shepazu | is puzzled why that's a problem |
| 19:35 | <shepazu> | it's not like that's a big implementation burden |
| 19:35 | <sayrer> | well, "src" would be three characters |
| 19:36 | <sayrer> | it is not hard to implement, I agree |
| 19:36 | <sayrer> | just verbose |
| 19:36 | <shepazu> | "r" would be one character |
| 19:36 | <shepazu> | the size of a data:URL is going to dwarf any attribute name |
| 19:37 | <sayrer> | but now I have to use namespaces |
| 19:37 | <sayrer> | or more than one, anyway |
| 19:37 | <sayrer> | always a sign of trouble |
| 19:37 | shepazu | is going to avoid this religious issue |
| 19:38 | <sayrer> | well, it's not religious in this case |
| 19:38 | <sayrer> | I don't need this to be extensible, so namespaces aren't helping much :) |
| 19:38 | <shepazu> | netsplit!!! run for your lives! |
| 19:39 | <sayrer> | shepazu, so are the features discussed in this appendix the same things I would find in SVG Tiny? |
| 19:39 | <sayrer> | or is there a table that explains this concisely somewhere? |
| 19:40 | <shepazu> | sayrer: not sure... look in SVG Tiny 1.1 for the featurestrings there |
| 19:40 | <shepazu> | I don't know of such a table, but I think it would behoove the SVG WG to make one |
| 19:41 | <shepazu> | I'm happy to bring that up, or champion it if you sent an email to www-svg explaining your use case |
| 19:41 | <sayrer> | well, I'm still exploring right now, so I think my explanation would be bad |
| 19:41 | <sayrer> | but I will do that eventually |
| 19:42 | <shepazu> | ok, that'd be great |
| 19:42 | <shepazu> | interestingly enough, I was just writing an email about how static SVG is taking off more and more |
| 19:44 | <sayrer> | it looks like the Mobile/Tiny stuff insists on interactivity |
| 19:45 | <shepazu> | sayrer: I think an SVG Core spec for static SVG, without interactivity or animation, would be interesting |
| 19:46 | <shepazu> | or SVG Static, whatever |
| 19:46 | <sayrer> | do you think it would take a long time to specify? or would it be a cut and paste job? |
| 19:46 | <shepazu> | it might be of interest to drawing tools and other scenarios where they think SVG is too heavy |
| 19:47 | <shepazu> | sayrer: more or less the latter |
| 19:48 | <shepazu> | but finding time and resources to do that within the WG might be hard, considering that most of the participants are interested in dynamic, scripted, animated, and interactive aspects of SVG |
| 19:49 | <sayrer> | seems like it would be uncontroversial as a W3C Note |
| 19:49 | <shepazu> | if this is of interest to Mozilla, and you put some resources in (and maybe helped find other participants who would do the same), I think we could do it |
| 19:49 | <shepazu> | I don't think it would be controversial as a spec, actually |
| 19:49 | <shepazu> | just a matter of resources |
| 19:49 | <sayrer> | tbh, I'm kind of dismayed it doesn't already exist, and wasn't considering resource allocation |
| 19:50 | <sayrer> | so I'll see how this goes |
| 19:50 | <shepazu> | ok, let me know |
| 19:50 | <shepazu> | like I said, that featurestring is a reasonable profile |
| 19:51 | shepazu | is curious what sayrer is planning... is this for Mozilla? |
| 19:51 | <sayrer> | yes, it is, but it's just my pet project |
| 19:51 | shepazu | guesses it's for Thunderbird |
| 19:51 | <shepazu> | that's cool |
| 19:51 | <sayrer> | nah, I don't work on Thunderbird much |
| 19:52 | Philip` | wonders what one would call a project about pets, to distinguish it from the term 'pet project' |
| 19:53 | <sayrer> | but this is unrelated to Firefox's general SVG stuff |
| 19:53 | <shepazu> | taxidermy? |
| 19:53 | <sayrer> | sorry I'm being so dodgy, I'm not ready to talk much about it |
| 19:59 | shepazu | was just watching a heron fishing in his backyard pond :D |
| 19:59 | <shepazu> | really cool, the way they move... keeping their head in the same position while they walk up underneath it for each step |
| 20:34 | hsivonen | really doesn't like the RELAX NG duplicate attribute prohibition |
| 20:50 | <zcorpan_> | i think it would be useful to look at text/html pages that have <math> or <svg> tags in order to figure out if the scoping proposal would break stuff |
| 22:58 | <Hixie> | haha shelley wants progress on the web to stop so that a book doesn't go out of date |
| 22:58 | <Hixie> | that's funny |
| 22:59 | <Pavlov> | that person work for microsoft? |
| 22:59 | <othermaciej> | frankly |
| 23:00 | <othermaciej> | if authors of books about web technology are frustrated at the rapid pace of progress |
| 23:00 | <othermaciej> | then I am happy |
| 23:00 | <gsnedders> | It means the web isn't stagnating. |
| 23:01 | <othermaciej> | but I think Shelley was more complaining about lack of roadmap |
| 23:01 | <othermaciej> | from the various engines |
| 23:02 | <Dashiva> | You don't really plan bugs ahead of time, and once you discover them holding back a fix for no good reason is kinda... odd. |
| 23:04 | <Hixie> | i don't even understand http://realtech.burningbird.net/semweb/wordpress-25-releases/#comment-696 |
| 23:04 | <Hixie> | i think what shelley is saying is that html5 shouldn't be easy because if it's easy people will use it instead of xhtml. |
| 23:07 | <Dashiva> | Does Shelley really think that with namespaces you can add new languages without the browsers needing to implement it first? |
| 23:07 | <Hixie> | a lot of people seriously think that |
| 23:07 | <Hixie> | a lot of people even think it's a good idea |
| 23:11 | <Hixie> | anyone have any web pages that use mathml that aren't, like, the blogs of editors of the spec or anything like that? |
| 23:11 | <gsnedders> | the spec == MathML? |
| 23:14 | <sayrer> | Hixie, Jacques Distler's pages? |
| 23:15 | <sayrer> | http://golem.ph.utexas.edu/~distler/blog/archives/001642.html#more |
| 23:15 | <sayrer> | for example |
| 23:16 | <Hixie> | yeah i have that one already |
| 23:16 | <Hixie> | but he might as well be on the committee :-) |
| 23:16 | <Hixie> | bbl lunch |
| 23:17 | Dashiva | wonders what a stretchy operator is |
| 23:18 | <sayrer> | Hixie, http://mathcast.sourceforge.net/fields.xml |
| 23:24 | <jgraham> | Dashiva: presumably something like http://www.pixar.com/featurefilms/incredibles/chars_pop2.html |
| 23:25 | <jgraham> | (seriously, it's something like a summation sign that needs to change size depending on what it operates on) |
| 23:45 | <webben_> | seen in #css: "is it possible to make a list go vertically upwards instead of downwards?" ... seem to remember this cropping up as a request before on the WHATWG/public-html lists. :) |
