| 00:27 | <Hixie> | Philip`: the text of the spec was written very much stream of consciousness. if we had the data, you could probably see a pattern as to when i use "... and ...", and "..., then ...", etc, based on who last talked to me, who I last replied to in e-mail, when I woke up, what i ate for lunch, or something :-) |
| 00:28 | jgraham_ | imagines the spec rewritten in the style of Ulysses |
| 00:28 | <jgraham_> | Although that should perhaps be styles |
| 00:28 | <jgraham_> | "styles", even |
| 00:55 | Philip` | wonders why lots of tests are failing, and then realises it's the head/body-implication thing where the spec disagrees with the tests |
| 01:03 | <Philip`> | Does someone happen to know how this ought to work? |
| 01:03 | <Hixie> | i really should fix that |
| 01:03 | <Hixie> | gah, so many things to fix |
| 01:03 | <Dashiva> | Speaking of implications. Whitespace nodes are sometimes processed as if the parser was in a different mode (e.g. in head noscript counts as in head" |
| 01:03 | <Dashiva> | Does this also normalize them if there's an existing one before or after already? |
| 01:03 | <Philip`> | (By "lots of tests", I mean 4 out of the 9 before I get a not-yet-implemented exception) |
| 01:03 | <Dashiva> | It says appending several characters means making them a single node, but it doesn't have specific mention of what happens when an append crosses phases |
| 01:20 | <Philip`> | Yay, now I pass 9 out of 9 tests before dying |
| 09:16 | <zcorpan_> | oooh |
| 09:16 | <zcorpan_> | xml 1.0 5th edition |
| 09:16 | <zcorpan_> | first step towards xml5? |
| 09:20 | <zcorpan_> | "XML 1.0 documents SHOULD NOT specify a version number other than '1.0'." |
| 09:21 | <zcorpan_> | seems they have made the version pseudo-attribute meaningless |
| 09:21 | <zcorpan_> | which is good |
| 09:32 | <zcorpan_> | wonder if they can be convinced to say that "XML 1.0 documents SHOULD NOT contain a DOCTYPE declaration." |
| 09:32 | <zcorpan_> | (or must not) |
| 09:33 | <annevk> | Philip`, when you hit EOF and you haven't created <head> yet, do that, etc., up until <body> |
| 09:45 | <Philip`> | I've done something like |
| 09:45 | <Philip`> | BeforeHead: (EndOfFile, [ActAsIfStartTag "head"; ReprocessCurrentToken]) |
| 09:45 | <Philip`> | InHead: (EndOfFile, [ActAsIfEndTag "head"; ReprocessCurrentToken]) |
| 09:45 | <Philip`> | AfterHead: (EndOfFile, [ActAsIfStartTag "body"; ReprocessCurrentToken]) |
| 09:45 | <Philip`> | Every other mode: same for EndOfFile as what the spec says |
| 09:45 | <Philip`> | which hopefully covers the necessary cases |
| 09:47 | <annevk> | i think html5lib has something like that |
| 10:57 | <jgraham_mibbit> | zcorpan_: What's the status of aria in HTML 5? Are we just planning to import all the aria properties as aria-* |
| 11:00 | <zcorpan_> | jgraham: think so |
| 11:00 | <zcorpan_> | the aria spec now requires only aria-* |
| 11:02 | <jgraham_mibbit> | That's the Member only WD, right? |
| 11:25 | <gsnedders> | zcorpan_: yeah, I think it's a good first step, though |
| 11:25 | gsnedders | realises how awesome school is: he is in secondary 5! |
| 11:42 | <zcorpan_> | jgraham_: no, a fpwd was published the other day |
| 11:42 | <zcorpan_> | jgraham_mibbit: http://www.w3.org/TR/wai-aria/ |
| 11:51 | <jgraham_mibbit> | zcorpan_: Thanks |
| 11:52 | jgraham_mibbit | wonders how aria properties are supposed to interact with html-native properties (e.g. <td aria-labelledby="foo" headers="baz"> |
| 11:52 | <jgraham_mibbit> | ) |
| 11:54 | <zcorpan_> | jgraham: i wonder that too |
| 11:55 | <zcorpan_> | i'm planning to go through each and every aria role and question its existance in the first place and furthermore how it interacts with native features in host languages |
| 11:56 | <jgraham_mibbit> | zcorpan_: That sounds very worthwhile. |
| 11:59 | <jgraham_mibbit> | (and something that I would be interested in working on) |
| 11:59 | <zcorpan_> | feel free :) |
| 12:01 | <zcorpan_> | i think that the host language should be able to say whether a role applies or not |
| 12:01 | <zcorpan_> | e.g. role=heading might make sense in svg but not in html |
| 12:04 | <annevk2> | why oh why did I reply to Dmitry Turin |
| 12:05 | <hsivonen> | do we have some kind of support for SVG diagrams in the mediawiki instance on wiki.whatwg.org? |
| 12:05 | <zcorpan_> | annevk2: your ignore flag isn't working properly |
| 12:12 | <annevk2> | :) |
| 12:12 | <annevk2> | this was my last reply |
| 13:27 | <zcorpan_> | hmm there's no spec for window.scrollTo and friends |
| 13:27 | <annevk2> | if you can propose definitions I'm willing to put them where they belong |
| 13:27 | <annevk2> | (cssom-view) |
| 13:28 | <zcorpan_> | i have to figure out which should throw when |
| 13:28 | <zcorpan_> | s/when/and when/ |
| 13:30 | <annevk> | is there a non-multipage shortcut for the WHATWG draft of HTML5? |
| 13:35 | <zcorpan_> | don't think so |
| 13:37 | <Philip`> | http://whatwg.org/html5/../ unfortunately doesn't work |
| 13:40 | <annevk> | http://html5.org/spec |
| 13:51 | Philip` | keeps getting mixed up between Ocaml's "!=" and "<>" operators |
| 13:51 | <Philip`> | which is annoying because it makes my code fail in ways that take me ages to discover :-( |
| 13:52 | <Philip`> | (!= and == do physical equality, = and <> do structural equality, so "x" = "x" and "x" != "x") |
| 14:20 | Philip` | notes that e.g. the "reconstruct the active formatting elements" algorithm does not map trivially into a functional language |
| 14:56 | <Philip`> | "1. Let node be the element immediately prior to node in the stack of open elements. 2. If node is not in the list of active formatting elements, then remove node from the stack of open elements and then go back to step 1." |
| 14:57 | <Philip`> | If node is removed from the stack of open elements, then there is no longer any element immediately prior to it in the stack of open elements |
| 14:57 | <Philip`> | or am I misunderstanding something? |
| 14:58 | <Dashiva> | node seems overloaded |
| 14:58 | <annevk> | the stack of open elements always has the root node |
| 14:59 | <annevk> | which can't be popped iirc |
| 14:59 | annevk | forgot the details |
| 15:00 | <Philip`> | But 'node' can be not the root node, and once it's removed from the stack then you can't find an element prior to 'node' in the stack |
| 15:00 | <annevk> | ? |
| 15:00 | <Philip`> | Like, what comes before node 'x' in the list [a; b; c; d]? |
| 15:01 | <Philip`> | Once 'x' has been removed from the list, that doesn't make sense any more |
| 15:02 | <annevk> | good point, which algorithm is this? |
| 15:03 | <Philip`> | Adoption agency |
| 15:03 | <Philip`> | though I don't know of many real adoption agencies that clone children |
| 15:04 | <annevk> | I think "node" and "node" in the first sentence are distinct |
| 15:07 | <annevk> | so that one of those "node" thingies is still around when you delete the other |
| 15:08 | Philip` | wishes the terms 'lower' and 'prior' and 'after' and 'furthest' and 'last' and 'end' and 'start' and 'bottom' weren't all mixed up for similar concepts |
| 15:09 | <annevk> | node = self.tree.openElements[ |
| 15:09 | <annevk> | self.tree.openElements.index(node)-1] |
| 15:09 | <annevk> | while node not in self.tree.activeFormattingElements: |
| 15:09 | <annevk> | tmpNode = node |
| 15:09 | <annevk> | node = self.tree.openElements[self.tree.openElements.index(node)-1] |
| 15:09 | <annevk> | self.tree.openElements.remove(tmpNode) |
| 15:10 | <annevk> | with better indentation is the html5lib impl of those two steps |
| 15:10 | <Philip`> | That's setting node to the element prior to node, before removing node |
| 15:10 | <Philip`> | which is the opposite order to what the spec says |
| 15:13 | <annevk> | i guess the spec needs to be clarified then |
| 15:13 | Philip` | will probably email something once he's worked out what's meant to be going on in the algorithm |
| 15:16 | <annevk> | bugs :( |
| 16:49 | <annevk> | gsnedders, someone else pointed out the changes I needed to make for ABNF fancyness |
| 16:50 | <gsnedders> | annevk: ah, so I need not do anything? |
| 16:52 | <annevk> | right, though you may review |
| 16:52 | <annevk> | and maybe answer a question |
| 16:52 | <annevk> | does ABNF do #rule ? |
| 16:52 | <gsnedders> | # being a number? yes |
| 16:52 | <annevk> | HTTP #rule |
| 16:53 | <gsnedders> | meaning what? |
| 16:53 | gsnedders | is slightly confused now |
| 16:56 | <annevk> | a comma-seperated list |
| 16:59 | Philip` | sees that the 'has an element in scope' algorithm deceptively is used in two quite different ways, one checking for a specific element and one checking for any element with a name in a given set |
| 17:07 | Philip` | wonders if anyone knows of a bug where Firefox on Linux shifts a random set of characters up or down by one codepoint |
| 17:07 | gavin | doesn't |
| 17:07 | <gavin> | sounds nasty! |
| 17:07 | <Philip`> | like changing all spaces into "!"s, or changing the world "element" into "dldmdnt" |
| 17:08 | <Philip`> | s/world/word/ |
| 17:08 | <gsnedders> | annevk: what's the original that you're trying to go from? |
| 17:08 | <Philip`> | I just saw it happen to someone, but he fixed it by restarting the browser |
| 17:10 | <annevk> | gsnedders, http://dev.w3.org/2006/waf/access-control/#access-control0 |
| 17:10 | <gsnedders> | annevk: that doesn't make sense in the original if it should be comma-seperated, off the top of my head |
| 17:12 | <gsnedders> | annevk: rule *("," *LWS rules) — I think that would do |
| 17:12 | <annevk> | the idea is to :allow <*>, deny <*>, allow <*> |
| 17:12 | <gsnedders> | s/rules/rule/ |
| 17:12 | <annevk> | do you need *LWS ? |
| 17:12 | annevk | thought LWS was already multiple |
| 17:13 | <gsnedders> | I have no idea. In RFC2616? |
| 17:13 | <gsnedders> | IIRC no |
| 17:13 | <gsnedders> | RFC2616 seems to use *LWS a lot |
| 17:14 | <gsnedders> | LWS = [CRLF] 1*( SP | HT ) |
| 17:14 | <gsnedders> | and it's implicit *LWS that's allowed in HTTP |
| 17:15 | <gsnedders> | RFC2616's BNF seems to have implicit commas, but ABNF doesn't |
| 17:15 | <gsnedders> | annevk: rule *(*LWS "," *LWS rule) |
| 17:16 | <gsnedders> | *LWS rule *(*LWS "," *LWS rule) |
| 17:16 | <gsnedders> | that's the equivalent |
| 17:16 | <annevk> | holy crap |
| 17:16 | <gsnedders> | RFC2616's BNF is made to make HTTP easy to spec in BNF |
| 17:17 | <gsnedders> | in most cases you don't want implicit comma separated lists |
| 17:17 | <annevk> | maybe I should use RFC2616 BNF |
| 17:17 | <gsnedders> | 2616bis may move to ABNF too, so maybe we get that there :) |
| 17:17 | <annevk> | as it's about HTTP after all |
| 17:18 | <annevk> | and i don't want it to be vastly different from HTTP |
| 17:18 | <annevk> | oh well, got to run |
| 17:18 | <gsnedders> | me too |
| 17:39 | Philip` | gives in and writes an imperative function |
| 18:05 | Philip` | gets half of the adoption agency algorithm to type-check |
| 18:28 | <Philip`> | So, I hope steps 6-8 are equivalent to: Remove all items from open-stack between furthest-block and formatting-element that are not in active-list. Set bookmark to be after the first element in that open-stack range that is also in active-list. Fold all the elements in that range into a tree, with some cloning, then fold that into common-ancestor. |
| 20:11 | <annevk> | http://norman.walsh.name/2008/02/07/xml105e |
| 20:14 | <hsivonen> | I suppose I should find time to write a comment to the effect of too little too late and causes uncertainty and interop problems to the very people it is supposed to help |
| 21:03 | <Lachy> | XML1 5th ed. sounds ok. Although I haven't read the spec, I assume new documents written that contain previously forbidden characters will fail well formedness checks in older parsers. |
| 21:03 | <Lachy> | I don't see that as a major problem, but there will be a significant transitional period |
| 21:59 | <gsnedders> | Lachy: your assumption is correct |
| 21:59 | <gsnedders> | Lachy: I doubt it'll take wrong, basically change 1.1 mode into 1.x mode |
| 22:07 | <jgraham_> | gsnedders: The relevant timescale is not the time to implement but the time for existing deployments to be updated |
| 22:07 | <jgraham_> | (asumming you meant s/wrong/long/) |
| 22:11 | <Philip`> | It'll be fun for people who try to be careful and do well-formedness checks before passing user-provided data into some backend system |
| 22:28 | <gsnedders> | jgraham_: yeah, I did |
| 22:28 | <gsnedders> | I'm too tired to typ |
| 22:28 | <gsnedders> | *type |
| 22:32 | <sayrer> | I have a way to work around the XHR issues that Microsoft has |
| 22:32 | <sayrer> | new XMLHttpRequest('<meta http-equiv="X-UA-Compatible" content="IE=8" />') |
| 22:32 | <sayrer> | that will trigger their compatibility mode |
| 22:33 | <Philip`> | Uh, how is that meant to work? |
| 22:34 | <sayrer> | perfectly! |
| 22:35 | <Philip`> | Oh, okay |
| 22:35 | <Philip`> | By what mechanism is that meant to work perfectly? |
| 22:35 | <sayrer> | AJAX |
| 22:36 | <Philip`> | *confused* :-( |
| 22:37 | <Philip`> | I still think Microsoft should run a database of all web pages to say what IE-compatibility mode they should be rendered with |
| 22:38 | <Philip`> | They've already got the right infrastructure from the phishing filter |
| 22:40 | <jgraham_> | Philip`: Given much of the problem is with intranet pages... |
| 22:53 | <annevk> | sayrer :) |
| 23:10 | Philip` | 's adoption agency appears to run forever |
| 23:12 | <annevk> | infinite childs |
| 23:14 | <takkaria> | not too unlike real life, then |
| 23:17 | <annevk> | pfff |
| 23:17 | <annevk> | i don't quite get this accountability thread |
| 23:21 | <annevk> | -> bed |
| 23:22 | <jgraham_> | Philip`: I think the html5lib adoption agency encountered a spec bug at first but it was fixed iirc |
| 23:39 | <Lachy> | nice. WebKit adds support for selectors api http://webkit.org/blog/156/queryselector-and-queryselectorall/ |
| 23:42 | <othermaciej> | oh yeah we should have mentioned that sooner |
| 23:42 | <othermaciej> | weinig had some comments about the spec actually but I don't think he submitted them to the webapi list |
| 23:42 | othermaciej | glares at weinig |
| 23:44 | <othermaciej> | Lachy: I think his particular comment was that being able to preflight a selector as one the engine could handle might be more convenient for JS libraries that would wrap this than the exception on syntax error |
| 23:44 | <othermaciej> | Lachy: since browser selector support may be variable, and libraries would want to fill in the holes |
| 23:45 | <aroben> | othermaciej: I think it didn't get announced until we passed the css3.info selector test |
| 23:45 | <aroben> | othermaciej: for exactly the reason of not wanting to be less capable than the JS libraries |
| 23:46 | <aroben> | othermaciej: since they don't have an easy way of know what we support |
| 23:46 | <aroben> | knowing |
| 23:46 | <othermaciej> | aroben: many JS libraries support nonstandard extensions to Selectors anyway |
| 23:46 | <aroben> | othermaciej: oh? |
| 23:47 | <othermaciej> | yeah |
| 23:47 | <othermaciej> | so either way they'll want to dispatch to a native implementation only conditionally |
| 23:47 | <othermaciej> | but I actually thing try/catch might be an ok way to achieve that |
| 23:49 | <aroben> | othermaciej: yeah, it's not so bad |
| 23:51 | Philip` | tries running through the adoption agency manually, and finds that it still loops infinitely... |