| 00:04 | <othermaciej> | Hixie: amusing |
| 11:23 | gsnedders | is tempted to do more work on HTTP parsing |
| 11:31 | <gsnedders> | Is it sensible to use ABNF but state that alternations must be matched from left to right? |
| 11:32 | <MikeSmith> | gsnedders: yeah, I think it would be. as long as you made that clear in the spec |
| 11:33 | <gsnedders> | It means I don't end up with things like: ( [ ":" *LWS ] 1*header-content-nc [ *LWS ":" ] / 1*":" / 1*header-content-nc 1*LWS ":" *LWS header-content [ *( header-content / LWS ) header-content ] ) *LWS |
| 11:33 | <gsnedders> | That was an attempt to give everything that doesn't match another rule :) |
| 11:34 | <Philip`> | If the order of matching is important, that sounds like a fundamental shift from the usual notion of a language grammar |
| 11:35 | <gsnedders> | *( %x00-09 / %x0B-FF ) LF is a lot simpler :) |
| 11:35 | <Philip`> | (since normally grammars just define a set of matching strings, and it's irrelevant how you matched it) |
| 11:36 | <gsnedders> | The URI spec relies upon such a restraint though |
| 11:37 | <Philip`> | It sort of sounds like you want to define a new type of alternative, such that "Rule1 / Rule2" matches if Rule1 matches or else if Rule1 doesn't match and Rule2 does match |
| 11:38 | <Philip`> | but that matches exactly the same as the normal type of alternative |
| 11:38 | <Philip`> | so I may be misunderstanding what you want |
| 11:38 | <gsnedders> | Peh. If anyone complains I'll just say that RFC 3986 and 3987 (URI and IRI respectively) do this too. |
| 11:38 | <Philip`> | s/exactly the same/exactly the same set of strings/ |
| 11:39 | <Philip`> | I suppose it makes more sense if you have an unambiguous grammar and you're interested in which rules match |
| 11:40 | <gsnedders> | Is there any way to easily work out a rule that represents everything that doesn't match another rule? |
| 11:40 | <Philip`> | in which case it seems like the 'correct' thing to do would be to define an AABNF which adds a new unambiguating-alternative rule |
| 11:41 | <Philip`> | because then it would be well defined and unambiguous and everything |
| 11:42 | <MikeSmith> | dammit |
| 11:42 | <MikeSmith> | Philip`: help me out please |
| 11:42 | <MikeSmith> | File "tools/spec-splitter.py", line 64, in ? |
| 11:42 | <MikeSmith> | parser = etree.HTMLParser(encoding='utf-8', recover=False) |
| 11:42 | <MikeSmith> | TypeError: 'encoding' is an invalid keyword argument for this function |
| 11:42 | <Philip`> | gsnedders: I don't think it is |
| 11:43 | <MikeSmith> | Philip`: missing python module? |
| 11:43 | <gsnedders> | Philip`: ? |
| 11:43 | <MikeSmith> | or a not-up-to-date one? |
| 11:45 | <Philip`> | gsnedders: ...but I could be wrong |
| 11:45 | <Philip`> | s/it is/there is/ |
| 11:45 | <gsnedders> | Oh, there is. |
| 11:46 | <gsnedders> | That makes a lot more sense. |
| 11:51 | <MikeSmith> | Philip`: my lxml too old, maybe? |
| 11:55 | <MikeSmith> | nm |
| 11:55 | <MikeSmith> | I'll run it from another host where I can actually make the sure packages are up to date |
| 12:00 | <Philip`> | gsnedders: Hmm, I'm probably wrong, but I don't know why |
| 12:01 | <Philip`> | MikeSmith: I think it requires lxml 2.0 |
| 12:01 | <Philip`> | but that's the only version issue I know of |
| 12:01 | <MikeSmith> | Philip`: yep, I think so. and I updating to 2.0 on the host I was trying this on would be too much of a PITA, so I'll just run it from my own server |
| 16:28 | <inimino> | gsnedders: what you describe is basically a PEG |
| 16:29 | <gsnedders> | a PEG? |
| 16:29 | <inimino> | rather than BNF |
| 16:30 | gsnedders | points out he isn't a compsci guy |
| 16:30 | <takkaria> | gsnedders: http://en.wikipedia.org/wiki/Parsing_expression_grammar |
| 16:43 | <gsnedders> | inimino: I do, however, need something formally defined to enough of an extent to use in a spec. |
| 16:45 | <inimino> | PEGs are quite formally defined, but if the protocol is byte-oriented you might want to use the ABNF notation for terminals anyway |
| 16:45 | <inimino> | it's fairly common to treat ABNF this way and there are even some parser generators that treat ABNF like something it's not |
| 16:46 | <inimino> | technically it's impossible to generate an efficient parser from an ABNF since they can be ambiguous |
| 16:52 | <gsnedders> | inimino: Yeah, right, I know. |
| 20:07 | <guyzmo> | hi |
| 20:08 | <guyzmo> | I'm parsing an html page with html5lib, and I get troubles when I want to get contents |
| 20:08 | <guyzmo> | like when I'm in an anchor element, shall I use toxml() to get the XXX part of : "<a>XXX</a>" ? |
| 20:08 | <guyzmo> | (haven't found any other way) |
| 21:10 | <GPHemsley> | Hixie: Why does section 11 of the HTML5 spec use the XHTML namespace while defining style for HTML5-only elements? |
| 21:18 | <Philip`> | GPHemsley: All HTML5 elements are parsed into the XHTML namespace |
| 21:36 | <GPHemsley> | Philip`: Oh. Is that implicit? |
| 21:37 | <Philip`> | GPHemsley: It's explicit in the spec that that happens, but the markup doesn't have to have any xmlns attributes or anything |
| 21:37 | <GPHemsley> | k |
| 22:15 | <GPHemsley> | What's the difference between <embed> and <object>? Is one favored over the other? |
| 22:20 | <jcranmer> | <embed> is specifically plugin related, IIRC |
| 22:20 | <jcranmer> | that is, I'm pretty sure an image/*-in-embed wouldn't work |
| 22:56 | <GPHemsley> | jcranmer: What about Flash? |
| 22:56 | jcranmer | doesn't know anything |
| 22:56 | <GPHemsley> | k |
| 22:57 | <GPHemsley> | Strangely, you also cannot style <object>, it seems. It styles the fall-back underneath. :/ |