| 01:30 | <Hixie> | why does lachy blogging mean that /feed/ on the blog gets hit a lot |
| 01:30 | <Hixie> | that makes no sense to me |
| 01:31 | <takkaria> | update services? |
| 01:31 | <Philip`> | Does "hit" mean number of requests, or number of requests that get a 200 response because they're not handled by any caching mechanism? |
| 01:33 | <Hixie> | the former |
| 01:39 | <jruderman_> | maybe feed readers that already noticed the new post are checking the feed again to pick up typo fixes and such? |
| 01:39 | <Hixie> | maybe |
| 02:42 | <Hixie> | what to do with tabindex="" |
| 02:42 | <Hixie> | dropping it altogether is very tempting |
| 02:44 | <takkaria> | Hixie: nice to see you watched Yes Minister fairly recently. :) |
| 02:47 | <Hixie> | hm? when? |
| 02:47 | <takkaria> | or maybe I'm just drawing more than can be drawn from the last-modified date of http://ian.hixie.ch/bible/handling-people |
| 02:48 | <Hixie> | the last change was the last section |
| 02:49 | <Hixie> | but october isn't recently, anyway :-) |
| 02:50 | <takkaria> | I'm one of those people who takes a long time to adjust to a change of year, it's only just got through to me that 2007 is almost four months away |
| 02:53 | <roc_> | Ian has been studying YES, MINISTER? That explains a lot |
| 02:56 | <Hixie> | in what way! |
| 02:57 | <Hixie> | hey! |
| 02:57 | <Hixie> | i don't know whether to be offended or not! |
| 02:57 | <takkaria> | Hixie: let's say, you've made some very courageous decisions. :) |
| 02:58 | <Hixie> | hey! |
| 04:13 | <Hixie> | is there any reason to allow tabindex="" on anything but <div>s? |
| 04:13 | <Hixie> | and maybe <span>s? |
| 04:15 | <jruderman_> | it's a lot more widely used than that... |
| 04:15 | <Hixie> | is it used in ways that improve matters? |
| 04:15 | <jruderman_> | hmm |
| 04:16 | <jruderman_> | wordpress used to get it totally wrong |
| 04:30 | <takkaria> | hmm, I dislike people who claim they provide JSON APIs when they actually provide JS APIs |
| 04:52 | <inimino> | takkaria: you mean people that didn't actually look at the definition of JSON? |
| 04:59 | <takkaria> | inimino: it shouldn't surprise me, really, but it does. :) |
| 08:17 | <hsivonen> | Hixie: ARIA uses tabindex |
| 08:19 | <Hixie> | does it use any value other than 0? |
| 08:19 | <hsivonen> | Hixie: -1, IIRC |
| 08:19 | <hsivonen> | tabindex is basically a backwards-compatible focusable |
| 08:19 | <Hixie> | -1 seems like it would be really bad for accessibility |
| 08:20 | <Hixie> | what's the point of a focusable field you can't focus? |
| 08:20 | <hsivonen> | http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices#11.3.1.1_HTML_5_Tabindex |
| 08:21 | <hsivonen> | Hixie: I don't know what the use cases for -1 are, but it seems that the three states are absent, -1 and 0 |
| 08:21 | <Hixie> | there are four states |
| 08:21 | <Hixie> | no wait, five |
| 08:22 | <Hixie> | no wait, six |
| 08:22 | <hsivonen> | Hixie: are you counting intrinsic focusability of form controls and links? |
| 08:23 | <Hixie> | absent and focusable and tabbable in automatic tab order, absent and not focusable, focusable but not tabbable, focusable and tabbable in automatic tab order, focusable and tabbable in fixed tab order |
| 08:23 | <Hixie> | and hypothetically, absent and focusable and not tabbable |
| 08:24 | <Hixie> | there is no "not focusable", which seems like it might be at least as useful as focusable but not tabbable |
| 08:24 | <othermaciej> | -1 allows programmatic focus |
| 08:24 | <Hixie> | othermaciej: programmatic _and mouse_ focus |
| 08:24 | <othermaciej> | I can see how it might be useful to have something focusable but not in the tab cycle |
| 08:25 | <Hixie> | e.g.? |
| 08:25 | <othermaciej> | (though that doesn't normally happen in Mac UI) |
| 08:25 | <jruderman> | a cell in a spreadsheet that is infinite in both directions? |
| 08:25 | <othermaciej> | control that has multiple possibly active elements and when it gets focus it focuses the "current" one |
| 08:26 | <Hixie> | fair enough |
| 08:26 | <othermaciej> | (that is essentially what a WebKit WebView does in Cocoa on Mac OS X, by analogy) |
| 08:27 | <hsivonen> | Hixie: what about an ajax widget that consists of multiple HTML elements and you want any of them to be clickable but you want the entire thing to appear once in the keyboard focus cycle? |
| 08:27 | <othermaciej> | perhaps you have a widget where the children are normally navigated by arrow keys instead of TAB for keyboardability |
| 08:28 | <othermaciej> | (in fact <select multi> is an example of such a control built into HTML) |
| 08:48 | <annevk> | given the use cases so far you could require that tabindex=-1 is always inside tabindex=0 |
| 08:53 | <Hixie> | some of the use cases just need one of n controls to be =0 |
| 08:54 | <Hixie> | and the others to be =-1 |
| 09:08 | <hsivonen> | annevk: what if you have a composite widget that is spread across two table cells and the nearest common ancestor contains a whole lot more than just that widget? |
| 09:21 | Hixie | updates his dilbert script to handle the new page |
| 09:21 | <Hixie> | dilbert.com are fighting the good fight |
| 09:21 | <Hixie> | giving people a reason to disable flash, by giving a better ui without flash than with |
| 09:23 | <Philip`> | The non-Flash UI used to be "You need to install Flash" four times |
| 09:23 | <Philip`> | Looks like they've fixed that now, which is nice |
| 09:23 | <Hixie> | the non-flash ui is now way better than the flash ui |
| 09:24 | <Hixie> | and it even shows it to you as the flash is loading |
| 09:24 | <Hixie> | to show you why you should disable flash |
| 09:42 | <sverrej> | hei hei |
| 09:42 | <sverrej> | /wrong channel |
| 09:45 | <hsivonen> | Hixie: if HTML5 is successful, the worse UI will be written in JS and canvas |
| 09:45 | <Hixie> | yep |
| 09:46 | <Hixie> | but at least people will be able to write interoperable implementations of players for those uis |
| 09:46 | <hsivonen> | yeah |
| 09:47 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#tabindex |
| 09:54 | <zcorpan> | hsivonen: so aria will need to work with canvas! |
| 09:56 | <othermaciej> | hsivonen: the problem with Flash is not just that it makes it easy to do weird, poorly integrated UI, but that it makes it hard to make natural UI that fits with the platform and the browser environment |
| 09:56 | <othermaciej> | I don't think HTML5 as a whoe has that problem |
| 09:56 | <othermaciej> | canvas gives you an out, but it's not the convenient, let alone only, path to making app-style UI |
| 09:57 | <annevk> | <canvas> is here to allow people to implement Super Mario and Doom :) |
| 09:58 | <Philip`> | It's kind of hard to do UI in a canvas when there's no text support |
| 09:58 | <Hixie> | yeah |
| 09:58 | <Hixie> | indeed |
| 09:58 | <Hixie> | we really need a solution to that |
| 09:58 | <Hixie> | it's a tough problem |
| 09:58 | <Hixie> | i'm thinking a drawText method that takes a rect |
| 09:58 | <Hixie> | and a font-size |
| 09:59 | <Hixie> | and tries rendering at that font-size, but if it won't fit at that size, it shrinks the text until it fits |
| 09:59 | <Hixie> | i can't see another good way of avoiding the unpredictable metrics problem |
| 09:59 | <annevk> | @font-face ? |
| 10:00 | <annevk> | also, that doesn't allow text along a path and such |
| 10:00 | <Hixie> | text along a path is far less critical |
| 10:00 | <Hixie> | as is render text to path |
| 10:00 | <Hixie> | though the latter could be done in a similar way with a arect |
| 10:01 | <Philip`> | A nasty problem with Mozilla's text drawing thing is the font size depends on the user's text size preferences, so it's very unpredictable |
| 10:01 | <Hixie> | yeah that's obviously a non-starter |
| 10:01 | <Philip`> | If the font size was just done in pixels, it'd be pretty much the same between most non-crazy fonts, so in practice it would work reliably enough in most cases |
| 10:01 | <Hixie> | requiring a TTF is an interesting idea |
| 10:01 | <Hixie> | Philip`: oh no, just compare verdana to tahoma or arial |
| 10:02 | <Hixie> | and that's just fonts on one platform |
| 10:02 | <Hixie> | hmm, requiring a ttf would be really funny for so many reasons |
| 10:02 | <annevk> | Lachy, I think datetime is actually Y10K proof |
| 10:02 | <Hixie> | i was talking to someone else earlier today about this |
| 10:03 | <Hixie> | and they suggested that html5 should just have an appendix that included a full unicode font |
| 10:03 | <Hixie> | that uas had to use for canvas |
| 10:03 | <Philip`> | I'm assuming "most cases" are where the font size isn't critical - you can have things like right/center aligned graph labels, and it doesn't matter if the text is somewhat wider since there's plenty of blank space to grow into |
| 10:03 | <annevk> | Hixie, wow, that's pretty drastic |
| 10:03 | <Hixie> | Philip`: many labels are going to abut the edge |
| 10:03 | <Hixie> | annevk: it wasn't a serious suggestion :-) |
| 10:04 | <Philip`> | Make the canvas infinite so there is no edge |
| 10:04 | <Hixie> | mmhmm |
| 10:04 | <Philip`> | (and render it infinitely, not just inside the <canvas> rectangle) |
| 10:04 | <Philip`> | Warning: bad idea |
| 10:07 | <hsivonen> | Hixie: the tokenizer spec would be nicer if the places where you have lookahead were written as states |
| 10:07 | <Lachy> | annevk, I thought the year was restricted to 4 digits |
| 10:07 | hsivonen | refactors them as states |
| 10:07 | Lachy | checks... |
| 10:09 | <annevk> | oh yeah, "not exactly four digits long" |
| 10:10 | <Lachy> | http://www.whatwg.org/specs/web-apps/current-work/#dates |
| 10:10 | <Lachy> | yep |
| 10:10 | <annevk> | that's inconsistent with http://www.whatwg.org/specs/web-forms/current-work/#date though so it's probably a bug |
| 10:10 | <Philip`> | http://www.rosettaproject.org/about-us/disk/concept - they want years >10,000 |
| 10:11 | <hsivonen> | annevk: I think I've raised the inconsistency as an issue |
| 10:11 | <annevk> | k |
| 10:12 | <annevk> | I don't see it in "semantics-phrasing" |
| 10:13 | <annevk> | hmm, might not be the correct place |
| 10:14 | <annevk> | ah, it's in "microsyntaxes-dates" |
| 10:15 | <annevk> | "Consistency of date formats between WF 2.0 and WA 1.0" |
| 10:16 | <annevk> | Hixie, is the 1-8 list at http://www.whatwg.org/issues/top still accurate? |
| 10:18 | <zcorpan> | seems like there aren't really enough votes to make the top list an actual top list |
| 10:19 | <zcorpan> | more like the latest pet issues |
| 10:19 | <annevk> | oh, i wasn't wondering about those |
| 10:19 | annevk | wondered about the "Ian's current priorities" list |
| 10:20 | <zcorpan> | ah |
| 10:26 | <Hixie> | annevk: not really |
| 10:26 | <Hixie> | annevk: i update it every now and then |
| 10:27 | <Hixie> | hsivonen: which cases are those? |
| 10:34 | <Hixie> | anyone got IE? |
| 10:35 | <Hixie> | nevermind |
| 10:35 | Hixie | fires up CVMWare |
| 10:36 | <Lachy> | I have IE8 |
| 10:37 | <hsivonen> | Hixie: inspecting if the next chars are the close tag in [R]CDATA and inspecting if the next chars are 'OCTYPE' |
| 10:38 | <hsivonen> | or UBLIC |
| 10:38 | <hsivonen> | or YSTEM |
| 10:38 | <Hixie> | how would you do those as states? |
| 10:39 | <hsivonen> | I'd have states that inspect for those strings incrementing an index into the reference string |
| 10:39 | <hsivonen> | and putting the characters also inte the same buffer that is used for comments so that if a switch to bogus comment comes, the start of the comment buffer is already correct |
| 10:40 | <annevk> | that wouldn't make the spec more readable imo |
| 10:40 | <hsivonen> | perhaps not in the OCTYPE, YSTEM and UBLIC cases |
| 10:41 | <Philip`> | I like it more when the spec says something obvious and I have to translate it into something efficient to implement, rather than when it says something efficient to implement and I have to reverse-engineer it in order to implement it differently |
| 10:41 | <hsivonen> | the close tag stuff in [R]CDATA could well be its own state in the spec |
| 10:42 | <hsivonen> | I'm refactoring the tokenizer to make it more friendly for cases where the tokenizer doesn't own the processing loop |
| 10:42 | <hsivonen> | I see three use cases: |
| 10:42 | <Hixie> | yeah i certainly wouldn't implement those cases as states |
| 10:42 | <Hixie> | that would be terrible for perf for me |
| 10:43 | <hsivonen> | Hixie: why would it be terrible for perf? |
| 10:44 | <Hixie> | because doing a strong comparison using my native string compare function is far faster than looping six times through my tokeniser function |
| 10:44 | <Hixie> | s/strong/string/ |
| 10:44 | <Philip`> | (The adoption agency is a case where I had to reverse engineer the algorithm before I could implement it sanely in OCaml, and it would have been nicer if the spec said what it was trying to achieve) |
| 10:45 | <Hixie> | yeah |
| 10:45 | <Hixie> | i'm not sure i know what it was trying to achieve |
| 10:45 | <Hixie> | i've only ever worked out what the AAA is in terms of what the spec sys |
| 10:45 | <Philip`> | Ah, okay :-) |
| 10:45 | <Hixie> | the spec is basically a direct brain dump from what i came up with |
| 10:46 | <hsivonen> | I think my current refactoring effort will make it easier to do a line-by-line port from Java to C[++]. |
| 10:46 | <hsivonen> | for apps that have a Gecko-style processin loop |
| 10:47 | <Philip`> | Hixie: Your brain is weird if you get a 22-step algorithm from a direct dump of it |
| 10:47 | <Hixie> | my brain is certainly weird |
| 10:48 | <Hixie> | for AAA i basically derived the algorithm on my whiteboards by black box testing |
| 10:48 | <Hixie> | and a lot of trial and error |
| 11:27 | <zcorpan> | http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx is interesting |
| 11:27 | <zcorpan> | also affects xml parsing |
| 11:30 | <annevk> | I wonder what happens in other browsers |
| 11:31 | <annevk> | other browsers seem to simply do what is requested |
| 11:32 | <annevk> | it crashes IE6 :) |
| 11:32 | <zcorpan> | yeah |
| 11:32 | <zcorpan> | in opera you can get text nodes as child of the document node |
| 11:32 | <zcorpan> | s/child/children/ |
| 11:33 | <zcorpan> | (with non-whitespace data) |
| 11:33 | <annevk> | that should prolly throw a HIERARCHY_REQUEST_ERR or something |
| 11:33 | <zcorpan> | i rather think we should do what webkit and firefox do |
| 11:34 | <annevk> | test snippet? |
| 11:40 | <othermaciej> | wow |
| 11:40 | <othermaciej> | I never would have even thought of handling that case with an error dialog which makes the page disappear when you click ok |
| 11:42 | <othermaciej> | that blog post is very vague about which browsers do what |
| 11:42 | <zcorpan> | annevk: http://dump.testsuite.org/2008/mutations-during-parsing/ ;) |
| 11:43 | <annevk> | :p |
| 11:43 | othermaciej | learns that webkit's xml parser does not enjoy mutation during parsing |
| 11:44 | <zcorpan> | othermaciej: webkit and firefox remember the modified dom and the parser drops elements or inserts them in the "new" place accordingly; opera assumes there were no mutations and just inserts elements blindly |
| 11:44 | <zcorpan> | s/elements/nodes/ |
| 11:44 | <zcorpan> | at least last time i tested |
| 11:45 | <othermaciej> | http://tinyurl.com/6cwsfj |
| 11:45 | <othermaciej> | that's Travis's example in Live DOM Viewer |
| 11:45 | <othermaciej> | Safari seems top be dropping everything that would have gone in the removed node |
| 11:46 | <Lachy> | so rather than actually find a solution that doesn't throw an error, they still throw the error and abort, but just not tell the user about it? That's only marginally better. |
| 11:46 | <zcorpan> | hmm safari 3.1 crashed for 002.xml |
| 11:47 | <annevk> | othermaciej, the definition for caretRangeFromPoint will be rather vague and UI dependent |
| 11:47 | <zcorpan> | othermaciej: has there been changes to xml behavior in safari lately? last time i tested 001 and 002 worked the same and 003 and 004 worked the same |
| 11:48 | <annevk> | i'm still not quite sure how to phrase it |
| 11:48 | <zcorpan> | iirc, anyway |
| 11:48 | <othermaciej> | zcorpan: I was somewhat surprised that 002 crashed |
| 11:48 | <hsivonen> | HTML5 already addresses this, doesn't it? |
| 11:49 | <hsivonen> | the tree builder keeps node references on its stack and potentially keeps appending to nodes that are no longer in the tree |
| 11:49 | <annevk> | hsivonen, it's mentioned |
| 11:49 | <annevk> | not sure if the exact final tree can always be determined |
| 11:49 | <zcorpan> | hsivonen: doesn't cover xml though |
| 11:49 | <annevk> | xml is tricky anyway |
| 11:50 | <annevk> | for some time some browsers did not do incremental rendering or script execution |
| 11:50 | <hsivonen> | zcorpan: seems to me that the XML tree builder also needs to have a stack of node references and avoid trusting that the parentNode chain can be used as stack |
| 11:51 | <Hixie> | i came across all these cases when writing teh html5 parser spec |
| 11:51 | <Hixie> | i probably even blogged about them |
| 11:51 | <Lachy> | I don't see what's so difficult about the case mentioned in the blog. |
| 11:52 | <hsivonen> | Hixie: I think we need a Web spec that defines an entity resolver and a DOM builder on top of a SAXish XML parser |
| 11:52 | <othermaciej> | the blog was a surprisingly circuitous way of saying that IE will still do something crappy, and other browsers do better, and Travis has a vague opinion on which of the other browser behaviors is better |
| 11:53 | <Lachy> | with my limited testing, Firefox seems to be behaving sensibly |
| 11:53 | <hsivonen> | it seems like there's a policy or habit of not naming competitors on the IE blog |
| 11:53 | <annevk> | Hixie, maybe you can help out defining caretRangeFromPoint? |
| 11:53 | <othermaciej> | I tried his test case in live dom viewer and it seemed that both firefox and safari dropped everything that would have gone in the removed element |
| 11:53 | <othermaciej> | which is not what I expected |
| 11:54 | <Hixie> | othermaciej: they don't drop it |
| 11:54 | <Hixie> | othermaciej: they put them in that element |
| 11:54 | <Hixie> | othermaciej: which is what html5 requires too |
| 11:54 | <othermaciej> | put them in that element which is already removed? |
| 11:54 | <Hixie> | othermaciej: html5's parser doesn't look at the dom at all (except for handling inlines) |
| 11:54 | <Hixie> | othermaciej: the element is still in the parser's stack |
| 11:55 | <Hixie> | you could put it in another document for all the parser cares |
| 11:55 | <Hixie> | anyway |
| 11:55 | <Hixie> | bed time |
| 11:55 | <Hixie> | nn |
| 11:56 | <othermaciej> | that sounds sensible to me |
| 11:57 | <annevk> | othermaciej, any suggestions for caretRangeFromPoint? |
| 11:57 | <othermaciej> | annevk: I dunno |
| 11:57 | <othermaciej> | I very much need to go to bed |
| 12:02 | <annevk> | hmm, i'll try something out |
| 12:02 | <othermaciej> | annevk: so in Safari (and I think we did this for FF/IE compatibility) clicking in a non-editable area creates an invisible caret selection |
| 12:03 | <othermaciej> | you could define caretRangeFromPoint to give the same range as the caret selection you would get clicking there |
| 12:03 | <othermaciej> | though perhaps that is too vague |
| 12:03 | <annevk> | "return an empty text range for the position where |
| 12:03 | <annevk> | a text insertion point indicator would have been placed if editing was |
| 12:03 | <annevk> | enabled and hit testing was performed at the coordinates x,y in the viewport" |
| 12:03 | <annevk> | is my start |
| 12:04 | <othermaciej> | that is not bad |
| 12:04 | <othermaciej> | I'm off to bed for now, later |
| 12:04 | <annevk> | bye |
| 12:04 | <Lachy> | wow, it seems the people on HTML4all are accepting that <acronym> isn't in HTML5 now. I thought many of those people objected to its exclusion previously. |
| 13:08 | <annevk> | http://dev.w3.org/csswg/cssom-view/#documentview-caretrangefrompoint |
| 13:13 | <heycam> | annevk, (nit:) missing a comma between "J. Ferraiolo" and "?? ?" |
| 13:13 | <heycam> | in the references section for SVG |
| 13:13 | <annevk> | thx |
| 13:13 | <annevk> | you're not pasting UTF-8 fwiw |
| 13:14 | <heycam> | really? :( |
| 13:14 | heycam | kicks his x-chat |
| 13:15 | heycam | wonders where the encoding options might be in x-chat |
| 13:21 | <heycam> | annevk, does this display properly now? 藤沢 淳 |
| 13:21 | <annevk> | yes |
| 13:21 | <heycam> | cool |
| 13:21 | heycam | afks |
| 13:26 | hsivonen | hopes HotSpot doesn't have some silly max size for the code of one method... |
| 13:29 | <Philip`> | hsivonen: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4262078 ? |
| 13:29 | <hsivonen> | Philip`: ouch |
| 13:30 | <Philip`> | It's not a bug, it's a feature - everyone agrees that methods should rarely be more than a screenful of code |
| 13:30 | <hsivonen> | Philip`: parser state machines are excempt |
| 13:30 | <hsivonen> | exempt |
| 13:31 | <Philip`> | On the subject of generated code, does JavaScript (or common implementations of it) have a maximum regexp size? |
| 13:31 | <hsivonen> | whew. the whole classfile is under 64KB |
| 13:32 | <Philip`> | My tokeniser has a /^(thetasym;|Epsilon;|Omicron;|Upsilon;|...|yen|GT|LT|gt|lt)/ to get longest entity-name matches, but I worry how that'll cope with MathML entities |
| 13:36 | <hsivonen> | which reminds me that I should email the list and complain about the MathML entities |
| 13:36 | Philip` | notes that Word 2007 appears to neither emit nor accept entities (other than the standard XML ones) |
| 13:36 | <Philip`> | (...in its MathML copy/paste system) |
| 13:37 | <hsivonen> | Word++ |
| 13:37 | <hsivonen> | some sanity with entities |
| 13:37 | <annevk> | Philip`, did you include a DTD? |
| 13:37 | <Philip`> | I've not seen it generate numeric entities either, it just does Unicode |
| 13:38 | <hsivonen> | Word++ |
| 13:38 | <annevk> | hsivonen, are you against entities? |
| 13:38 | annevk | likes them a lot for hand authoring |
| 13:38 | <Philip`> | annevk: Whenever I added a DTD, it just pasted as plain text (the same as any normal non-XML paste operation) |
| 13:42 | <Philip`> | (...and the same as any XML paste operation whose root element isn't <math xmlns=whateveritis>) |
| 13:43 | <annevk> | ok |
| 13:46 | <hsivonen> | annevk: adding MathML entities violates our design principles |
| 13:46 | <hsivonen> | annevk: they add a backwards-incompatible way of doing something that can already be done in a backwards-compatibel way |
| 13:48 | <zcorpan> | and there are only 2 persons who are hand authoring mathml anyway |
| 13:49 | <zcorpan> | and even if you are, you can only remember &invisibleTimes; and a few others anyway |
| 13:50 | <zcorpan> | not all 2000 |
| 13:50 | <zcorpan> | at which point, looking up the unicode code point becomes as much of a hassle as looking up the mathml entity name |
| 13:50 | <Philip`> | The entities don't make MathML much easier to write, but they do make it much easier to write |
| 13:50 | <Philip`> | Uh |
| 13:51 | <Philip`> | The entities don't make MathML much easier to write, but they do make it much easier to read |
| 13:51 | <zcorpan> | why would you read mathml markup? |
| 13:51 | <annevk> | to change it |
| 13:51 | <Philip`> | i.e. it's easy to see what 'a&invisibleTimes;b' means, but not what 'a―b' means |
| 13:51 | <annevk> | zcorpan, we need to cater for the copy-and-paste-and-learn authoring crowd |
| 13:51 | <annevk> | it made the Web big |
| 13:53 | <annevk> | (and also for the hand authoring crowd... it's not at all clear that MathML hand authoring will remain a niche market once it becomes more approachable) |
| 13:53 | <Philip`> | (The HTML syntax doesn't seem to make MathML any more approachable) |
| 13:54 | <annevk> | once it's implemented it will |
| 13:54 | <Philip`> | (It's just as verbose, and you can't even tell when you've accidentally missed out an end tag and got your nesting all wrong) |
| 13:54 | <zcorpan> | annevk: entities can be added when there are enough handwriting mathml authors to make it justifyable :) |
| 13:54 | <Philip`> | (so if anything it's harder to write by hand in HTML than in XML) |
| 13:54 | <annevk> | Philip`, i don't think that's the issue, the issue is that making XML documents is way harder |
| 13:54 | <annevk> | zcorpan, chicken/egg |
| 13:55 | <hsivonen> | annevk: Unicode input in an issue between you and your editor. don't bother my browser with it, please |
| 13:55 | <annevk> | zcorpan, and since entities are cheap |
| 13:55 | <hsivonen> | s/in/is/ |
| 13:55 | <annevk> | hsivonen, why would i want to write additional scripts for my text editor if the browser can do it? |
| 13:56 | <annevk> | (and if it makes my source code more approachable so i can understand what i wrote later on) |
| 13:56 | <hsivonen> | annevk: why should my browser replace your Character Palette or whatever the Gnome equivalent is called? |
| 13:56 | <annevk> | so that i don't have to write converters myself |
| 13:57 | <hsivonen> | annevk: I think straight Unicode is (apart from invisibleTimes) more readable |
| 13:57 | <Philip`> | annevk: You don't think the verbosity of MathML is an issue for hand-authoring? |
| 13:58 | <annevk> | Philip`, I don't know |
| 13:58 | <annevk> | hsivonen, that's hard to type |
| 13:59 | <annevk> | … is easier for me than looking up the Unicode character |
| 13:59 | <hsivonen> | annevk: not in Mathematica |
| 13:59 | <hsivonen> | annevk: your input method just sucks |
| 13:59 | <annevk> | which typically involves copying from data:text/html,… |
| 14:00 | hsivonen | presses option-period |
| 14:00 | <annevk> | hsivonen, that tools will save us is a fallacy imo |
| 14:00 | <annevk> | i don't think we should design for that when making Web formats |
| 14:00 | Philip` | often finds it hard to write equations in LaTeX without losing track of all the nested brackets and braces, and MathML adds an order of magnitude more syntax to get in the way |
| 14:00 | <annevk> | they should ideally all be doable using a simple text editor |
| 14:01 | <annevk> | otherwise we might as well get compiled javascript, compiled html+css, etc. |
| 14:01 | <Philip`> | (The only way I can manage is by having the source code and the PDF output side by side, which works alright) |
| 14:02 | <Philip`> | hsivonen: There are many more text editors than there are HTML parsers, so shouldn't the complexity be put in the HTML parsers so it doesn't have to be implemented so many times? |
| 14:02 | <hsivonen> | Philip`: you should put the complexity in the OS input method |
| 14:03 | <hsivonen> | Philip`: Math is complex like Japanese |
| 14:03 | <hsivonen> | Philip`: Math should have an IME, too |
| 14:05 | <Philip`> | hsivonen: How should things like special space characters be handled? They're impossible to edit unless the text editors renders them in some special way (i.e. not as blank spaces), so editors will still have to cope with that complexity |
| 14:05 | <Philip`> | s/renders/render/ |
| 14:06 | <hsivonen> | Philip`: they need editor cooperation, yes |
| 14:06 | <hsivonen> | Philip`: Word has had a feature to show formatting characters for ages |
| 14:07 | <annevk> | why require simple text editors to have math support when supporting some additional entities is trivial? |
| 14:07 | <annevk> | (and is already required for XML content anyway) |
| 14:07 | <hsivonen> | annevk: I'll reply in email to list |
| 14:13 | <Philip`> | The problem with getting the OS to provide a nice input method for Unicode maths symbols is that I don't expect my OS's developers to make a nice input method for that :-p |
| 14:14 | <Philip`> | and if someone did make one, it'd have a silly name and I'd never even hear of it so it wouldn't help me |
| 14:14 | <annevk> | expecting the OS to have an IME for math also doesn't make sense as math requires some kind of markup |
| 14:15 | <annevk> | where Japanese is just characters |
| 14:15 | <Philip`> | I used to have Windows set up so ctrl+shift+9 switched to a Greek keyboard layout, which was quite useful for maths, but I've never worked out how to make KDE do that |
| 14:16 | <annevk> | so while I agree that Japanese requires some complexity I don't think it makes sense to then also require that for stuff like … or &invisibleTimes; |
| 14:16 | <annevk> | or ë etc. |
| 14:17 | <Philip`> | Maths is mostly ASCII with occasional funny symbols, whereas (I assume) Japanese is entirely funny symbols, so it's much easier to convince a Japanese person to learn how to use an IME |
| 14:18 | <Philip`> | (and easier for them to remember how to use it, since they use it all day every day, rather than using it half a dozen times and then not using it again for two weeks and then forgetting how it works) |
| 14:20 | <Philip`> | (But maybe the IME would still be no harder to learn and remember than the short list of MathML entity names you commonly want to use, in which case that's not a relative disadvantage) |
| 14:23 | <hsivonen> | email sent |
| 14:25 | <annevk> | what triggered this hsivonen? |
| 14:25 | annevk | is curious |
| 14:26 | <annevk> | never mind |
| 14:26 | <hsivonen> | annevk: hellip has been typable on Apple keyboard layouts since the 1980s! like this … |
| 14:27 | hsivonen | can also type euml: ë |
| 14:27 | <Philip`> | AltGr+[ e gives me ë |
| 14:28 | <Philip`> | I can write "..." which works perfectly adequately |
| 14:28 | <Philip`> | (Maybe fonts should define a ligature for "...") |
| 14:29 | <annevk> | hsivonen, doesn't work so well for me, and it's not too good for legacy systems, such as dev.w3.org |
| 14:29 | <annevk> | better to stay ascii compatible there |
| 14:29 | <hsivonen> | annevk: even the OS X handwriting recognition can do ë even in the English mode! |
| 14:30 | <hsivonen> | annevk: the input methods on your OS just suck |
| 14:30 | <hsivonen> | and it's a solved problem |
| 14:31 | <annevk> | apparently not |
| 14:31 | <annevk> | also, i just mentioned, dev.w3.org and w3.org docs in general work better if you stay ascii only |
| 14:31 | <annevk> | (that also doesn't address the other arguments pointed out earlier) |
| 14:31 | <hsivonen> | it's sad if w3.org can't do UTF-8 |
| 14:32 | <annevk> | it can |
| 14:32 | <annevk> | but by default it would display as ISO-8859-1 |
| 14:32 | <annevk> | and lots of times people do just that so sticking with entities is safer |
| 14:33 | <hsivonen> | annevk: do you value that safety over backwards compat? |
| 14:34 | <zcorpan> | annevk: how about changing the default? |
| 14:34 | <annevk> | i would, if browsers support mathml entities i would start using them |
| 14:34 | <annevk> | rendering the &...; string in older clients is acceptable to me |
| 14:34 | <annevk> | zcorpan, they fear that would break too much |
| 14:35 | <annevk> | zcorpan, this is just an example though, i'm sure there's more out there :) |
| 14:49 | Philip` | wonders if he should put his canvas tests under some sort of licence |
| 14:49 | <Philip`> | It seems nobody has actually cared about that yet (or at least not complained enough for me to hear) |
| 15:21 | <Lachy> | I hate entities except for < >, &, ". For everything else, writing the real character is better |
| 15:21 | <Lachy> | makes the source code easier to read when it has the real character instead of some entity ref |
| 15:22 | <Lachy> | oh, and entities for invisible characters like are ok, but normally I prefer the numeric reference |
| 15:24 | <zcorpan> | Lachy: why do you prefer the numeric reference? |
| 15:24 | <Philip`> | Lachy: Do you mean you normally prefer the numeric references including for characters like , or only for non-invisible characters? |
| 15:25 | <annevk> | I think disliking entities is some kind of phase. Just like people disliking text/html |
| 15:25 | <Philip`> | I don't like text/html |
| 15:25 | <Philip`> | It's just less bad than some alternatives |
| 15:26 | <Philip`> | and I'm not sure that's a phase, because it seems quite factual that text/html is ugly and broken :-) |
| 15:26 | <annevk> | Actually, it may be more similar to liking XHTML-in-text/html over HTML-in-text/html |
| 15:28 | <annevk> | Some kind of syntax preference |
| 15:28 | <takkaria> | I've grown to like missing lots of opening and closing tags in text/html |
| 15:30 | <Philip`> | takkaria: Does 'lots' include the html/head/body tags? |
| 15:31 | <Philip`> | (Nowadays I always skip those whenever possible, just to be unconventional) |
| 15:31 | <takkaria> | yeah |
| 15:31 | <Lachy> | zcorpan, when I need an nbsp, I use the numeric reference   because. Similarly for any other non-printable charcters I may use. |
| 15:31 | <takkaria> | also </li>, but for some reason not </p> |
| 15:32 | <Philip`> | Lachy: (Did you mean to give a reason after saying "because"?) |
| 15:33 | <Lachy> | because it works in both HTML and XHTML |
| 15:33 | <Philip`> | Ah |
| 15:34 | <Philip`> | It seems easier to just not write XHTML by hand, rather than choosing to make HTML harder to write by hand |
| 15:34 | <Lachy> | but I don't consider it wrong to use them in HTML, and others can use them if they like. It's just my personal prefernce |
| 15:35 | <Lachy> | Although, when it comes to adding additional entities, I really don't see the use case that's being addressed by it and share hsivonen's backward compatibility concerns |
| 15:36 | <Philip`> | Including adding entities to <math> content? |
| 15:37 | <Lachy> | the only possible reason to allow them is to allow copying and pasting of MathML directly into HTML nad have it work, but that wouldn't work for XHTML anyway without using an XHTML+MathML DOCTYPE that browsers recognised |
| 15:37 | <Lachy> | s/nad/and/ |
| 15:38 | <Philip`> | It would be useful to know how many MathML-editing tools generate code with MathML entities, because I assume we want people to be able to copy-and-paste the output from them (modulo XML headers) into HTML |
| 15:39 | <Philip`> | (Namespace prefixes are easy to find-and-replace away, but entities aren't) |
| 15:40 | <Lachy> | if authors want to hand code and use entities, they should use a pre-processor that replaces them with either numeric references or the real characters |
| 16:03 | <annevk> | why? |
| 16:09 | <Lachy> | note my previous statement only applies to additional entities that aren't already supported in HTML, and it's because of the backwards compatibility issues |
| 16:10 | <annevk> | the compat issue is minimal imo |
| 16:10 | <Lachy> | the use case for mathml enties is minimal imo too |
| 16:10 | <Lachy> | *entities |
| 16:12 | <annevk> | it helps with hand authoring and porting of some existing mathml content |
| 17:23 | <annevk> | http://developers.slashdot.org/developers/08/04/24/1455202.shtml |
| 17:25 | <zcorpan> | good that consensus is forming at the WC3 |
| 17:25 | <zcorpan> | but what does warcraft3 have to do with html5? |
| 17:26 | <gsnedders> | LOL |
| 17:27 | <Philip`> | It must be referring to the Www Consortium Company inCorporated |
| 17:28 | <annevk> | oh, http://www.sdtimes.com/content/article.aspx?ArticleID=32067 quotes Michael Smith too |
| 17:31 | Dashiva | chuckles at "specialized experts" |
| 17:31 | <Philip`> | It's more useful to be a generalised expert |
| 17:32 | <takkaria> | why do people insist on thinking that the canvas API needs experts when it's already implemented mostly-interopably between browsers? |
| 17:32 | <takkaria> | "Some deprecated elements--center, /front/, and striks--were dropped in favour of CSS" |
| 17:33 | <Philip`> | takkaria: Because the canvas API can be extended to do more things (like, say, text, and dashed lines), and it's useful to have people will knowledge/experience/insight/etc when developing that |
| 17:34 | <Philip`> | takkaria: s/striks/strike/ |
| 17:34 | <Philip`> | and s/favour/favor/ |
| 17:34 | <Philip`> | those being your typos, not the article's :-p |
| 17:34 | <takkaria> | yeah, the paste was only half-complete. :) |
| 17:35 | <hsivonen> | nice to read Microsoft's position and the WG consensus from Slashdot |
| 17:36 | <takkaria> | Philip`: fair point. I always got a slightly different vibe, though, along the lines of "hmm, we need experts to design a graphics API" regardless of the current spec and implementation |
| 17:36 | <Philip`> | Anyway, seems like there isn't really any new information there - people think HTML5 is too large, and it would be easier to manage if there were smaller specs, but Hixie is too useful and everybody wants to let him do it all |
| 17:39 | <Philip`> | takkaria: Experts could also be considered useful for making the API spec more precise and correct and complete, without changing the actual API |
| 17:40 | <Philip`> | But I do agree the vibe you get seems reasonable given what people have said, though I don't know whether it's correct or not, but anyway it's pretty easy to ignore people who want to make incompatible API changes because that's just not going to happen |
| 17:42 | <Philip`> | At least nobody seems to have suggested that we need architectural consistency between canvas and SVG |
| 17:50 | <takkaria> | Philip`: I think they have, actually, but briefly and have been ignored |
| 17:53 | <annevk> | hsivonen, indeed :) |
| 17:54 | <annevk> | Philip`, to the extent possible we need arhictectural consistency imo |
| 17:55 | <annevk> | Philip`, that is, allow for as much backend code reuse as possible |
| 18:00 | <Philip`> | annevk: It depends on how far back you consider the backend to be - it's good to share the drawing primitives (like using Cairo for both), but not good to redefine canvas in terms of SVG (or vice versa) (because that would certainly make the specs consistent, but wouldn't help implementations) |
| 18:00 | <Philip`> | so I would just be worried if people suggested the latter option :-) |
| 18:01 | <annevk> | Philip`, your definition of architectural consistency scarely resembles that of some members of the Forms WG |
| 18:03 | <Philip`> | It usually sounds to me like their idea of architectural consistency is to redefine HTML forms in terms of the XForms processing model |
| 18:03 | <Philip`> | (hence being sort of analogous to redefining canvas in terms of SVG) |
| 20:21 | <gsnedders> | Anyone want to write RFC 4291 Version 5? |
| 21:12 | <Hixie> | hsivonen: i don't understand what an "entity resolver and a DOM builder on top of a SAXish XML parser" would be |
| 21:16 | <Lachy> | Hixie, wouldn't that be a rough description of what the HTML5 parsing spec is? |
| 21:18 | <annevk> | Hixie, basically, a spec that says how to create a DOM tree, when to execute scripts, what happens with entity references that can't be resolved, etc. |
| 21:18 | <Hixie> | oh |
| 21:18 | <Hixie> | isn't that xml5 |
| 21:19 | <annevk> | yeah, though I guess hsivonen was hinting at something like that for XML 1.0 |
| 21:20 | <hsivonen> | Hixie: the entity resolver part would make Gecko's entity catalog normative |
| 21:20 | gsnedders | keeps on saying he'll doing something about helping with XML5, then never does |
| 21:20 | <hsivonen> | Hixie: the DOM builder part would specify that the DOM builder must maintain its own node stack and must not rely on being able to follow parentNode o pop |
| 21:20 | <hsivonen> | on pop |
| 21:21 | <Hixie> | yeah |
| 21:21 | <Hixie> | it would be great for xml1.0 to have a well-defined parser spec, yes |
| 21:21 | <hsivonen> | it shouldn't even be hard to write |
| 21:21 | <Philip`> | Would it be harder to convince people to implement it? |
| 21:22 | <Hixie> | i'm declaring this "not my problem" |
| 21:22 | <gsnedders> | My main issue is the only place where I'd ship such a thing is written in PHP. Userland code is slowwww. |
| 21:23 | <hsivonen> | Philip`: if HTML 5 made Gecko's entity resover behavior normative for XHTML5, I'd implement it in Java in a reusable way |
| 21:24 | <Lachy> | hsivonen, would that require the use of magic PUBLIC identifiers in DOCTYPES to enable the feature? |
| 21:25 | <hsivonen> | Lachy: yes |
| 22:53 | Hixie | comments on the slashdot post to say he agrees with microsoft |
| 22:58 | <Philip`> | Hixie: You're replying far too late, nobody's even going to see your message :-p |
| 23:04 | <Hixie> | excellent |
| 23:11 | <Lachy> | Hixie, was that the slashdot post about the GPL? |
| 23:11 | <Hixie> | html5 |
| 23:12 | <Hixie> | http://slashdot.org/comments.pl?sid=533346&cid=23184908 is pretty much exactly right |
| 23:12 | <Lachy> | oh, I didn't even see that post before :-) |
| 23:15 | <Lachy> | any particular sections you think should be taken on by other editors, if they were available? |
| 23:17 | <Philip`> | I'd expect that depends a lot on who the editor is - some will find some sections really boring, and they wouldn't do any work on it for years, but might find other sections interesting and be happier to work on them |
| 23:18 | <Philip`> | so you can't define a single ordered list of things that should be extracted from the spec |
| 23:18 | <Hixie> | lachy: first, we need editors for the sections that even i have abandoned: http://wiki.whatwg.org/wiki/Companion_specifications |
| 23:19 | <Philip`> | Hixie: Those all look like really boring things :-) |
| 23:19 | <Hixie> | why do you think i abandoned them! |
| 23:20 | <Lachy> | once I can get selectors api mostly out of the way, into CR, I may be able to look at taking one of those on |
| 23:20 | <hsivonen> | what would be an example of a server-side DOM3 Core feature? |
| 23:20 | <Lachy> | although, I've got the html5 guide and xbl primer to work on still |
| 23:20 | <Philip`> | Hixie: It doesn't seem very effective to try recruiting editors by pointing them at a list of really boring things and saying they should work on those first |
| 23:21 | <Hixie> | Philip`: are there non-boring things? |
| 23:21 | <Hixie> | spec writing is hard work and pretty boring |
| 23:21 | <Dashiva> | Surely 3d canvas at least should be (relatively) exciting |
| 23:21 | <Hixie> | brb |
| 23:21 | <Lachy> | I like writing specs more than some of my other responsibilities at work |
| 23:21 | <Philip`> | Hixie: Probably not, but maybe there are some things that are just quite boring and not really boring :-) |
| 23:22 | <Hixie> | Philip`: css3 animation would be fun |
| 23:22 | <Dashiva> | Don't worry Lachy, next year someone else will be the coffee boy |
| 23:22 | <Hixie> | hough difficult |
| 23:23 | <Philip`> | Dashiva: I'd guess 3d canvas is mostly trying to work out what all the OpenGL state is and what functions depend on it and how to be sure browsers don't crash or have security bugs when people trying calling functions in a crazy order |
| 23:23 | <Lachy> | Dashiva, I wish we had a decent coffee boy! All we have are machines that make terrible hot chocolates, and canteen staff that keep filling the Nesquik container with poor quality substitues. |
| 23:23 | <Philip`> | which still isn't great fun |
| 23:24 | <Philip`> | (and then it'll still be a source of all sorts of bugs, just because video drivers are buggy) |
| 23:25 | <Lachy> | isn't there supposed to be a joint task force with the webapi wg to work on the canvas stuff? |
| 23:27 | <Lachy> | ah, that's in the proposed web api charter. I guess it will start after that charter takes effect |
| 23:27 | <Philip`> | The fun way to write specs would be to write lots of crazy demos and games and things, and say that any implementation which can run those demos is following the spec well enough |
| 23:28 | <Philip`> | Lachy: http://wiki.whatwg.org/wiki/Companion_specifications ? |
| 23:28 | <Philip`> | Uh |
| 23:28 | <Philip`> | Forgot to copy |
| 23:28 | <Philip`> | Lachy: http://www.w3.org/2007/12/WebApps-Charter-2007 ? |
| 23:28 | <Lachy> | yep |
| 23:29 | <Dashiva> | Lachy: I figured chaals had set you up with a proper espresso machine. My mistake :) |
| 23:55 | <Hixie> | http://developers.slashdot.org/comments.pl?sid=533346&cid=23190802 |
| 23:55 | <Hixie> | not sure how to reply to that in a way that doesn't insult the people working on that spec... |
| 23:55 | <Philip`> | Has that ever stopped you before? |
| 23:59 | <Lachy> | just explain that xhtml modularisation is a completely different concept from splitting up the HTML5 spec |