| 00:01 | <jptix> | hello |
| 00:01 | <jptix> | i'm implementing a browser automation tool that has a quasi-DOM as part of its API |
| 00:01 | <jptix> | my idea is to generate that code from the XHTML and/or HTML5 spec, keeping it easy to maintain |
| 00:02 | <jptix> | at the minimum i'll just need a map of { «tag name»: [«attribute», ...], ... }, but also some type info would be nice (e.g. 'disabled' => boolean) |
| 00:02 | <jptix> | any tips on where to start or any code that does something similar already would be greatly appreciated |
| 00:03 | <webben> | jptix: what happens if you need to automate something involving elements/attributes the browser supports that aren't conforming in HTML5? |
| 00:04 | <jptix> | webben: probably add it manually or have the user do browser.attributeValue("some-attribute") |
| 00:04 | <jptix> | s/browser/element |
| 00:05 | <jptix> | at the moment i'm just playing with the idea.. having at least some part of the code generated from the spec |
| 00:06 | <jptix> | am i heading down the wrong road here? |
| 00:07 | <webben> | it's an interesting idea |
| 00:07 | <webben> | not sure how good an idea it is ;) |
| 00:08 | <webben> | if worst comes to worst you could extract that programmatically from the spec's source, I guess. |
| 00:08 | <webben> | e.g. grab all dl.element instances |
| 00:10 | <jptix> | yes, that's the least appealing approach :) |
| 00:12 | <jptix> | i've been looking at the relaxng files in https://whattf.svn.cvsdude.com/syntax/trunk |
| 00:12 | <jptix> | but wanted to check if anyone here have an opinion |
| 00:13 | <jptix> | not sure if those are kept up to date |
| 00:13 | <webben> | that looks better |
| 00:13 | <jptix> | they seem to be |
| 00:15 | <webben> | jptix: I /think/ those are used by hsivonen's validator, in which case I would assume they're reasonably up-to-date |
| 00:18 | <webben> | jptix: out of interest why a "quasi-dom" rather than a dom? |
| 00:19 | <jptix> | webben: i'm re-implementing an existing API which has a quite large user base |
| 00:21 | <jptix> | so the "quasi" part is mostly about making it fit nicer to the language (ruby) |
| 00:21 | <jptix> | but hopefully it will be more accurate if my approach succeeds :) |
| 01:13 | <AryehGregor> | Ugh, camelCase property values for image-rendering. Can't we just systematically hyphenize, like CSS things are systematically camelCased when they need to be JS identifiers? |
| 01:15 | <AryehGregor> | Oh, I see, SVG is responsible for introducing zillions of camelCase values for CSS properties? Great. |
| 02:46 | <JonathanNeal> | Hi all! |
| 03:26 | <TabAtkins> | Ah, hacking in HTML and CSS is so relaxing. |
| 03:29 | <JonathanNeal> | Hacking in HTML, of course. |
| 03:29 | <JonathanNeal> | Injecting <plaintext> tags into forums that allow html. |
| 03:31 | <ment> | btw how does html serialization rutine deal with plaintext? |
| 03:38 | <ment> | because "<plaintext>data" gets serialized as "<plaintext>data</plaintext>" |
| 04:24 | <ment> | hooray |
| 04:24 | <ment> | my html5 parser is finally able to parse it's specification |
| 09:24 | <Mathias> | I have an HTML5 markup-related question |
| 09:25 | <Mathias> | If I was to use HTML5 for this page: http://optiekockerman.be/merken, what would be the best way to mark up the list of brands? (Which is basically the only "content" on that page) |
| 09:25 | <Mathias> | Would it be okay to use a secondary <nav> element? |
| 10:27 | <gsnedders> | ment: It doesn't really cope with plaintext, but the current whacky behaviour is already done and avoids special casing it |
| 11:40 | <gsnedders> | What does "'NoneType' object is unsubscriptable" mean? |
| 11:41 | <Philip`> | x = None; y = x[0] |
| 11:42 | <gsnedders> | When it's throwing on print repr(self.currentToken["name"])? |
| 11:42 | <Philip`> | self.currentToken is None |
| 11:42 | <gsnedders> | Ah, just realized that |
| 11:42 | gsnedders | facepalms |
| 11:42 | <Philip`> | Don't worry, it's easy to miss when the error message tells you precisely what the error is :-p |
| 11:45 | gsnedders | finds a fairly major bug in his tokenizer |
| 11:47 | <jgraham> | Philip`: To be fair it would be nicer if it knew what the variable name was |
| 11:53 | <gsnedders> | Where do end tags have their names lowercased? |
| 11:53 | <gsnedders> | (in the tokenizer) |
| 11:54 | gsnedders | finds a fairly major bug in the test runner |
| 11:55 | <gsnedders> | (we only ever run one test of each test with multiple content model flags) |
| 11:55 | <gsnedders> | Oh well, that's not really relevant any more |
| 11:55 | <Philip`> | gsnedders: Looks like emitCurrentToken lowercases all tag names |
| 11:56 | <gsnedders> | So all tags should go through that? Or everything? |
| 11:56 | <gsnedders> | Currently most doesn't go through that |
| 11:57 | <Philip`> | Looks like all tokens except errors and characters go through that |
| 11:58 | <gsnedders> | Down to 12 test failures… |
| 12:01 | <gsnedders> | Hmm, spec changed with expected result of <xmp>foo</xmp |
| 12:02 | <Philip`> | nonXmlBMPRegexp = re.compile(u'[\x00-,|/|:-@|\\\\[-\\\\^|`|\\\\{-\xb6|\xb8-\xbf|\xd7|\xf7|...') |
| 12:03 | <Philip`> | Am I mistaken, or is that completely bogus? |
| 12:04 | <Philip`> | It's matching characters which are in the range \0 to ',', or '|', or '/', or '|', or ..., or '\', or '\', or in the range '[' to '\', ... |
| 12:04 | <jgraham> | Philip`: Could be |
| 12:06 | <Philip`> | For example, it doesn't match ']' |
| 12:07 | <Philip`> | (whereas it does match '[') |
| 12:09 | gsnedders | wonders why spec editing stopped on the 27th |
| 12:09 | <gsnedders> | Is there any way to get more on http://html5.org/tools/web-apps-tracker? |
| 12:09 | gsnedders | guesses the answer is hack the code and ping annevk |
| 12:10 | <Philip`> | gsnedders: Because there were 0 bugs that weren't serious enough to be issues, and therefore the spec was perfect and needed no further editing |
| 12:10 | <gsnedders> | :P |
| 12:11 | <jgraham> | Philip`: Do feel free to fix it btw |
| 12:11 | <jgraham> | Since clearly I am a bozo |
| 12:11 | <Philip`> | I hate how the Google Code issues list intercepts the '/' key to focus the search box |
| 12:11 | <Philip`> | and therefore means I can't do find-in-page like I want to |
| 12:13 | <jgraham> | gsnedders: Issue 96 is irrelevant. The code is never run (it is used to build the incorrect regexp) |
| 12:13 | <jgraham> | It shouldn't block 1.0 |
| 12:14 | <gsnedders> | It wasn't going to block anyway :P |
| 12:14 | <gsnedders> | So RAWTEXT and RCDATA now don't have comments? |
| 12:15 | <jgraham> | gsnedders: That's not what you said in the issue tracker :p |
| 12:15 | <Philip`> | jgraham: Might try to fix it some time; just filed an issue for now |
| 12:15 | <jgraham> | gsnedders: I think that is correct |
| 12:16 | <gsnedders> | Priority-High was stuff I wanted to get in, but not block |
| 12:17 | <jgraham> | gsnedders: It was maked Release-1.0 |
| 12:17 | <gsnedders> | [u'EndTag', u'xmp', False] — how come that has a False explicitly there? |
| 12:18 | <jgraham> | Philip`: Your regexp doesn't work does it? You need to escape special characters like [ surely? |
| 12:18 | <gsnedders> | OK, so two of these test failures I'm pretty sure are spec bugs |
| 12:19 | <gsnedders> | The rest are tests needing updating |
| 12:22 | <Philip`> | jgraham: You only need to escape ']', and '-' if it's not at the start/end of the regexp, and '^' if it's at the start |
| 12:23 | <Philip`> | Oh, and '\' I guess |
| 12:32 | gsnedders | has a tokenizer that passes all the test cases now! |
| 12:33 | <gsnedders> | HG: changed python/src/html5lib/html5parser.py |
| 12:33 | <gsnedders> | HG: changed python/src/html5lib/inputstream.py |
| 12:33 | <gsnedders> | HG: changed python/src/html5lib/tokenizer.py |
| 12:33 | <gsnedders> | HG: changed python/tests/test_tokenizer.py |
| 12:33 | <gsnedders> | HG: changed testdata/tokenizer/contentModelFlags.test |
| 12:33 | <gsnedders> | HG: changed testdata/tokenizer/escapeFlag.test |
| 12:33 | <gsnedders> | HG: changed testdata/tokenizer/test3.test |
| 12:33 | <gsnedders> | Small commit. |
| 12:33 | <gsnedders> | (There are still two test failures, actually, but they're spec bug) |
| 12:37 | <gsnedders> | Oh, woops, html5parser shouldn't be in that commit |
| 12:40 | <jgraham> | Does anyone have a favourite way to set the idness of the "id" attribute |
| 12:40 | <gsnedders> | DOCTYPEs! |
| 12:40 | jgraham | thinks DOM3 Element.setIdAttribute might be the way forward |
| 12:41 | <jgraham> | gsnedders: Yeah but injecting false doctypes is bad if we want to preserve the fact that documents with no doctype have no doctype |
| 12:41 | gsnedders | notes that doesn't help minidom |
| 12:41 | <jgraham> | gsnedders: I think it does |
| 12:42 | <jgraham> | Oh. |
| 12:42 | <jgraham> | It only works if the element already has an attribute with the name "id" |
| 12:43 | <gsnedders> | WHAT!? |
| 12:43 | <jgraham> | Well that is out then |
| 12:43 | <gsnedders> | DOM-- |
| 12:43 | <jgraham> | s/with the name id/with the name you are trying to set as the id attribute name/ |
| 12:44 | <jgraham> | gsnedders: Well if sort of makes sense if you don;t think there should be hidden state |
| 12:44 | <jgraham> | Sadly, what we want right now is hidden state :( |
| 12:47 | <gsnedders> | Where does setIdAttribute come from? |
| 12:47 | <gsnedders> | Ah, it is in core |
| 12:48 | <gsnedders> | I guess all we can do is loop over all elements with @id and set setIdAttribute |
| 12:48 | <gsnedders> | Or, more likely, do it when creating the element with attributes |
| 12:51 | <jgraham> | gsnedders: That is worse than the current behaviour |
| 12:51 | <gsnedders> | jgraham: How so? |
| 12:51 | <jgraham> | Because it leads to surprisin, hard to predict, bugs rather than obvious "this doesn't work at all" bugs |
| 12:51 | <gsnedders> | jgraham: Why? |
| 12:52 | <jgraham> | Speifically if someone adds a node to the document after thay have parsed it then it won't have the idness set right |
| 12:52 | <jgraham> | Or if they add an id attribute to an existing element |
| 12:52 | <gsnedders> | Gah. Yeah. |
| 12:53 | <gsnedders> | then dtd is the only option. |
| 12:53 | <gsnedders> | (w00t) |
| 12:53 | <jgraham> | Yes but it will cause everything to get a DTD when serialized even if it didn't start with one |
| 12:54 | <gsnedders> | Yeah. |
| 12:54 | <gsnedders> | Can we parse with a DTD then replace the DTD via removeChild and document.implementation.createDocumentType and appendChild? |
| 12:55 | <jgraham> | I previously thouht I couldn't dislike DOM more. Now I realise that that was a mee mild distate compared to my current loathing |
| 12:55 | <jgraham> | *mere |
| 12:55 | <jgraham> | *distaste |
| 12:56 | <jgraham> | gsnedders: I have no idea if that will work or do something surprising |
| 12:56 | <gsnedders> | jgraham: Nor do I |
| 12:56 | <gsnedders> | jgraham: Can you think of any other fix? |
| 12:56 | <jgraham> | I suspect any new elements created will not get the idness set |
| 12:58 | <jgraham> | There is a fixed list of doctypes that trigger quirks mode, right? |
| 12:58 | <gsnedders> | No |
| 12:58 | <gsnedders> | It's a list of stuff that if it starts with x… |
| 12:58 | <gsnedders> | RTFS :P |
| 12:59 | <jgraham> | I am but it's slow :( |
| 13:02 | <jgraham> | And makes my computer very hot :( |
| 13:04 | <jgraham> | Anyway we could invent a new quirks-mode doctype and teach our serializer to strip it out |
| 13:05 | <jgraham> | It seems very ugly though :( |
| 13:05 | <gsnedders> | But then how do deal when there are DOCTYPEs in the document? |
| 13:05 | <gsnedders> | How do we get them to round trip? |
| 13:05 | <jgraham> | I thought we could edit them now? |
| 13:05 | <jgraham> | Oh I see |
| 13:05 | <jgraham> | Erm. |
| 13:05 | <gsnedders> | You can only have one DOCTYPE in a document. |
| 13:05 | <jgraham> | Yeah I know |
| 13:06 | <gsnedders> | I guess we could add in the internal subset idness |
| 13:06 | <jgraham> | Indeed |
| 13:06 | <jgraham> | The only quetion is what happens on serialization |
| 13:06 | <gsnedders> | Oh man, this is ugly. |
| 13:06 | <gsnedders> | The seriailizer ignores any internal subset |
| 13:06 | <jgraham> | our serializer would be fine |
| 13:07 | <jgraham> | gsnedders: I suggest we try your approach for the no-doctype case first to see if it works |
| 13:07 | <gsnedders> | Which? Adding doctype and removing it? |
| 13:07 | <jgraham> | gsnedders: yeah |
| 13:07 | <gsnedders> | I'd try that for both cases. |
| 13:07 | <jgraham> | I doubt it will work but you never know |
| 13:07 | <gsnedders> | (But I won't actually, so you do it) |
| 13:08 | <gsnedders> | impl dependant, I bet :P |
| 13:08 | <gsnedders> | Should I push the new tokenizer and break the parser as a whole or just wait for an even bigger push and merge? |
| 13:13 | <jgraham> | in what way break? |
| 13:14 | <gsnedders> | The parser changes content model flag, and that doesn't exist any more. |
| 13:14 | <gsnedders> | So loads parses wrong. |
| 13:19 | <gsnedders> | Also a fair amount of script related changeds |
| 13:19 | <gsnedders> | *changes |
| 13:19 | <gsnedders> | The simple stuff that can be fixed has got us down to 560 test failures |
| 13:20 | <gsnedders> | (five tree builders) |
| 13:20 | <gsnedders> | So 56 test failures |
| 13:23 | <gsnedders> | Quite a lot of broken tests due to no longer having comments |
| 13:24 | <jgraham> | gsnedders: Don't push yet |
| 13:25 | <gsnedders> | What's expected of <script> <!-- </script> --> </script>x now? |
| 13:27 | <gsnedders> | A script whose content is " <!-- " right? |
| 14:06 | gsnedders | notes buying stuff from a Swedish website when you can't understand the checkout system is hard |
| 14:10 | <gsnedders> | Oh, wait, I don't have a personnummer so I can't buy anything. |
| 14:10 | <gsnedders> | Actuallh, no. |
| 14:11 | <gsnedders> | This is weird. |
| 14:12 | <gsnedders> | Huh. |
| 14:12 | <gsnedders> | Now it didn't ask me for my card details. |
| 14:13 | <gsnedders> | Oh, now it asks for them after you have placed your order, and your order is on hold until you pay. |
| 14:13 | <gsnedders> | Wow. wierd. |
| 14:14 | <gsnedders> | And now my card is refused. Oh dear. |
| 14:15 | gsnedders | gives up |
| 15:53 | <TabAtkins> | Can anyone join the irc.w3.org:80 server? I wanna know if it's just something to do with the airport wifi killing it, or if the server is having problems. |
| 15:56 | <Philip`> | TabAtkins: I appear to be connected to it |
| 15:56 | <TabAtkins> | Philip`: Thanks. It's something on my end, then. |
| 15:57 | <Philip`> | TabAtkins: Maybe try the normal port, not :80 (since proxies might mangle that one)? |
| 15:57 | <TabAtkins> | Nah, no-port just times out. |
| 15:58 | <TabAtkins> | Eh, I'm stealing wifi anyway. No biggie. I'll just go play some Civ 4. |
| 16:00 | <jgraham> | gsnedders: Which website? |
| 16:54 | gsnedders | wonders if he has the bandwidth to manage to listen to spotify at the moment |
| 16:54 | <gsnedders> | jgraham: dustinhome.se |
| 17:18 | Philip` | has dust in his home and never had to go through any online checkout service to get it |
| 17:20 | gsnedders | realizes he should be testing this in shipping browsers as he has Safari hang |
| 17:20 | <gsnedders> | (and I know Opera 10 hangs) |
| 17:22 | gsnedders | now has a simple test suite harness that fails to work in all shipping browsers |
| 17:22 | <gsnedders> | (Though the reason why the test harness fails is the tests themselves) |
| 17:23 | <gsnedders> | Oh, and crashes the copy of WebKit I have here. |
| 17:24 | <gsnedders> | This really does reinforce the idea of there being nowhere near enough DOM tests. |
| 17:31 | <gsnedders> | Web DOM Core test suite results: latest shipping Safari and Opera: crash; latest shipping Firefox: FAIL (but completely the test suite!); latest shipping IE: fails almost everything. |
| 17:32 | <gsnedders> | s/ly/s/ |
| 20:38 | gsnedders | notes updating html5lib once it falls out of sync with the spec is a horrible task |
| 20:39 | <jgraham> | gsnedders: It would be better if you would note a way to make it easier |
| 20:39 | <gsnedders> | jgraham: keep it in sync with a specific revision of the spec |
| 20:39 | <jgraham> | (fwiw I have found the same which is likely why I haven't worked too much on it) |
| 20:39 | <jgraham> | gsnedders: ? |
| 20:39 | <jgraham> | You mean jus never update it? |
| 20:39 | <gsnedders> | at the moment it's basically a copy of the June spec with random things updated from the spec since |
| 20:40 | <gsnedders> | It's the fact it doesn't match any revision of the spec at the moment that is annoying |
| 20:40 | <gsnedders> | I mean I should always be able to say that html5lib implements revision x of the spec. |
| 20:42 | <jgraham> | gsnedders: Generally the best you can do is to say that it passes the tests |
| 20:42 | <jgraham> | It would be good if tests were kept in lockstep with the spec |
| 20:42 | <gsnedders> | The problem is the tests often don't match a specific revision of the spec :P |
| 20:48 | <gsnedders> | the problem with it not matching any version of the spec is having to go through the spec manually with the impl checking that it matches it |
| 20:48 | <jgraham> | That I can agree with. But given that it is impossible to tell which tests need to be updated |
| 20:48 | <Dashiva> | gsnedders: Make separate branches for each rev :D |
| 20:49 | <jgraham> | it is hard to see how you get the tests to match |
| 20:50 | <gsnedders> | Keep them up to date always? |
| 20:51 | <gsnedders> | Yeah, sure, you will probably end up with incorrect expectations at times, but once the impl catches up… |
| 20:53 | <jgraham> | gsnedders: How do you know which tests need to be updated when the spec changed? |
| 20:55 | <Dashiva> | Well, if each test has metadata saying which sections it applies to... and you go through each diff looking at which sections changed (and which were renumbered)... |
| 20:56 | <gsnedders> | jgraham: magic |
| 20:56 | <jgraham> | Dashiva: Each test could depend on dozens of sections. Annotating them all makes writing tests prohibitivly expensive |
| 20:57 | <Dashiva> | Well, if maintenance is too expensive, then consider tests to be throw-away |
| 20:58 | <jgraham> | Eh? |
| 20:58 | <Dashiva> | Mark each with "was valid at rev x" and if it starts failing, either discard it or update it |
| 20:58 | <gsnedders> | jgraham: Seriously though, it may be possible to use regex to find tests effected! |
| 20:58 | <gsnedders> | *affected(?) |
| 21:00 | <Philip`> | Seems like the easiest solution is to keep the implementation always up to date |
| 21:00 | <Philip`> | and always passing all tests |
| 21:00 | gsnedders | nominates jgraham to keep it up to date |
| 21:01 | <jgraham> | Dashiva: That doesn't seem to fix the underlying problem |
| 21:01 | <jgraham> | You still need to dig through the spec to decide if the test is wrong or the implementation is wrong |
| 21:03 | <Dashiva> | That's what the discard option is for. Then at a later point you can do bulk update/rewrite of related tests |
| 21:04 | <jgraham> | That sounds like a medicine that is worse than the disease. You fail a test you throw away the test rather tahn workin out if it is a real bug or not |
| 21:04 | <jgraham> | Seems to defeat the point of having tests |
| 21:04 | <Dashiva> | You're the one saying updating them is prohitively expensive, though |
| 21:07 | <jgraham> | Dashiva: I'm saying it's prohibitively expensive to create tests where you also have to work out all the section transitions |
| 21:07 | <jgraham> | It's already bad enough with the parse errors |
| 22:30 | <nicferrier> | I have a question about forms |
| 22:30 | <nicferrier> | is this the best place to ask it? |
| 22:30 | <nicferrier> | let me blunder on |
| 22:30 | <webben> | nicferrier: depends what the question is i guess |
| 22:31 | <nicferrier> | what I want to know is whether there is any thinking about server side validation |
| 22:31 | <nicferrier> | the new forms stuff is great |
| 22:31 | <nicferrier> | extra declarative syntax for validation |
| 22:31 | <nicferrier> | but it only affords client side validation |
| 22:31 | <nicferrier> | the validation will have to be repeated on the server side |
| 22:31 | <nicferrier> | and I wondered if anyone was thinking about that |
| 22:31 | <AryehGregor> | I hope so. :) |
| 22:32 | <webben> | nicferrier: It will and they are. |
| 22:32 | <AryehGregor> | HTML5 only specifies a syntax, it doesn't provide an implementation. If you use any client-side validation, obviously you need server-side validation too. |
| 22:32 | <webben> | nicferrier: HTML5 can't make the need for serverside validation disappear. |
| 22:32 | <AryehGregor> | How this actually works in practice is up to you. |
| 22:33 | <nicferrier> | yup, I appreciate it's not *exactly* in the bounds of html 5 |
| 22:33 | <AryehGregor> | webben, yes it can, just mandate that all clients use down-to-the-metal DRM, require servers to reject connections from inappropriately authenticated clients, and only sign the binaries of clients that are written personally by Ian Hickson. Duh. |
| 22:34 | <webben> | lol |
| 22:34 | <Hixie> | if only some people weren't actually doing that kind of thing |
| 22:34 | <nicferrier> | however, we're getting to a point where the rendered form is almost good enough to use as the DRY for an app |
| 22:34 | <nicferrier> | and I've been thinking about that and wondered if anyone else was. |
| 22:35 | <AryehGregor> | What's a DRY? |
| 22:35 | <nicferrier> | dont repeat yourself. |
| 22:35 | <AryehGregor> | The rendered form of what, then? |
| 22:36 | <webben> | nicferrier: well, you /could/ preprocess the form and derive serverside validation rules from the html, I guess, but that would be kinda weird. |
| 22:36 | <Hixie> | nicferrier: i don't think anyone has formally looked at taking html5 client-side markup and using it literally on the server side |
| 22:36 | <AryehGregor> | It's always a pain in web stuff that you're more or less forced to have different code doing server-side and client-side validation. |
| 22:36 | <nicferrier> | I mean that an html 5 form can potentially exist as a single statement of the form, instead of their being another version inside a framework |
| 22:36 | <Hixie> | nicferrier: xforms has been used in this way |
| 22:36 | <AryehGregor> | So you're saying like feed the actual HTML of the form into your abstraction framework, instead of specifying it in some other way? |
| 22:36 | <webben> | only really works for very very simple forms |
| 22:36 | <AryehGregor> | That would work if you had an HTML5 parser handy on the server side . . . |
| 22:36 | <nicferrier> | Hixie: exactly |
| 22:37 | <AryehGregor> | webben, well, presumably you'd have the ability to add extra validation (on client and/or server side) in whatever framework we're talking about. |
| 22:37 | <nicferrier> | I am saying the frameworks model could be generated from the html 5 syntax, yes. |
| 22:38 | <webben> | AryehGregor: well, yes, but then you're repeating yourself. |
| 22:38 | <nicferrier> | no, I'm not |
| 22:38 | <nicferrier> | it's just a representation |
| 22:38 | <nicferrier> | anyway, even if I am I don't have to type it again |
| 22:38 | <AryehGregor> | webben, not if the extra validation is beyond what HTML5 can represent. Then you have each requirement stated only once. |
| 22:38 | <AryehGregor> | nicferrier, I think that's a great idea as soon as all major web programming languages get HTML5 parsing libraries. |
| 22:39 | AryehGregor | isn't going to hold his breath for PHP on shared hosts |
| 22:39 | <webben> | AryehGregor: Ah, if you generate the client and serverside validation from a single rule definition, yes. |
| 22:39 | <webben> | but then you could just as well generate the HTML form from such rule definitions |
| 22:39 | <AryehGregor> | Yes, of course. |
| 22:39 | <AryehGregor> | That's how MediaWiki does it, where it actually uses such abstractions. |
| 22:40 | <AryehGregor> | (i.e. virtually nowhere, yet) |
| 22:40 | <nicferrier> | but what I'm saying is, that other than the obvious "this member must be in this set" the html5 validation rules are plenty good enough |
| 22:40 | <webben> | I'm not sure how having two types of inputs - rather than just a set of rules - helps. |
| 22:40 | <nicferrier> | for a base form definition. |
| 22:40 | <nicferrier> | the advantage being that forms are a lingua franca |
| 22:41 | <nicferrier> | designers and programmers speak forms. |
| 22:41 | <webben> | yes, but both need to be driven by domain models |
| 22:41 | AryehGregor | gets suspicious when he hears terms like "domain models" |
| 22:42 | <nicferrier> | :-) |
| 22:42 | <nicferrier> | my designers would disagree |
| 22:43 | <nicferrier> | but anyway, nobody is actively doing anything with this to anyone's knowledge. |
| 22:43 | <nicferrier> | that's cool. thanks people. |
| 22:46 | <webben> | nicferrier: Not /quite/ what you're proposing, but close: http://simonwillison.net/2003/Jun/17/theHolyGrail/ |
| 22:48 | <nicferrier> | yeah, writing the code to do it isn't hard |
| 22:48 | <nicferrier> | deciding on a usable model is a little harder |
| 22:48 | <webben> | nicferrier: usable model in what sense? |
| 22:49 | <nicferrier> | should the form be kept as a separate entity? |
| 22:49 | <nicferrier> | should we talk about documents and xpaths to forms? |
| 22:49 | <AryehGregor> | Let's just have every app reinvent the wheel and write its own form support badly. That's always worked for me. |
| 22:49 | <webben> | ^this ;) |
| 22:49 | <nicferrier> | AryehGregor: :-D |
| 22:49 | AryehGregor | wishes it weren't true |
| 22:49 | <webben> | nicferrier: "talk about documents and xpaths to forms" ... what would that mean? |
| 22:50 | <AryehGregor> | It's especially bad when you have to cater to shared hosts, in PHP, where lots of the useful libraries are written in C and only installable by root. |
| 22:50 | <AryehGregor> | s/ shared hosts, in//;s/PHP,.*$/PHP./ |
| 22:50 | <nicferrier> | webben: idk... just idle thoughts... maybe form = somedocument.forms["someform"] |
| 22:50 | <nicferrier> | value = form.field.value |
| 22:50 | <nicferrier> | that short of thing |
| 22:51 | <nicferrier> | binding an html5 form into a pl |
| 22:51 | <webben> | nicferrier: oh, you mean, would you keep all forms in an app in a single HTML document? |
| 22:51 | <nicferrier> | just thinking. |
| 22:51 | <nicferrier> | webben: well, I mean how would you keep them |
| 22:51 | <nicferrier> | if I want to pass the form through xslt |
| 22:52 | <nicferrier> | sorry, not expressing this very well |
| 22:52 | <nicferrier> | if the html5 form is authoritative |
| 22:52 | <nicferrier> | then it has to be wholly a resource |
| 22:52 | <nicferrier> | rather than being put together with bits of information from different places |
| 22:52 | <nicferrier> | it has to be an entity of itself |
| 22:53 | <webben> | how would the forms be made? hand edited? built with some sort of gui tool? |
| 22:53 | <nicferrier> | does it matter? |
| 22:53 | <webben> | a bit |
| 22:53 | <webben> | if I was going to hand edit such things, I'd prefer them kept in individual files. |
| 22:53 | <nicferrier> | an html5 form could be constructed by either hand or machine |
| 22:54 | <nicferrier> | hmm |
| 22:54 | <webben> | (just as I split out individual models, or templates, or testcases or whatever into their own individual files |
| 22:54 | <nicferrier> | a dynamic form would require a dynamic validator |
| 22:54 | <nicferrier> | dynamic meaning it depends entirely on the resource |
| 22:55 | <nicferrier> | consider a ticket editor that lets you edit all the tickets of a particular query |
| 22:55 | <nicferrier> | the http resource is the query |
| 22:55 | <nicferrier> | the representation is an html 5 entity with a single form |
| 22:55 | <nicferrier> | with fieldsets for each ticket |
| 22:55 | <nicferrier> | we can change a bunch of tickets to closed and then press submit |
| 22:57 | <webben> | nicferrier: hmm. in that scenario aren't you generating the form from a model, and if not that, how? |
| 22:57 | <nicferrier> | webben: well, yes. tricky. |
| 22:59 | <webben> | nicferrier: I guess you could build a two way system. That is, a system that can take a form as input and generate models and validation rules; or take a model as input and generate forms and validation rules? |
| 23:00 | <webben> | that way, for example, the designers could hand you a form, you could express the form in HTML, the system would generate a model and validation rules. |
| 23:00 | <nicferrier> | is the only thing that would ever change for a dynamic form the number of fieldsets? |
| 23:01 | <webben> | No? |
| 23:01 | <webben> | Even if you consider bugzilla tickets, the form varies depending on the lifecycle stage of the ticket. |
| 23:02 | <webben> | e.g. if a ticket has been CLOSED you have to REOPEN it before you can ASSIGN it. |
| 23:02 | <nicferrier> | but those are different forms |
| 23:02 | <nicferrier> | true |
| 23:02 | <webben> | depends what you mean by different form I guess. |
| 23:02 | <webben> | they are a little bit different |
| 23:02 | <nicferrier> | not different resources tho, you are right |
| 23:02 | <nicferrier> | in a RESTfull sense, same resource |