| 09:18 | <Charl> | ok let's test it and see if it works |
| 09:51 | <hsivonen> | morning |
| 09:52 | <hsivonen> | Lachy: If I guess correctly what Sam is going to suggest, I have intended to suggest the same thing |
| 09:52 | <hsivonen> | that is put <math> subtrees in the MathML namespace and <svg> subtrees in the SVG namespace |
| 09:52 | <hsivonen> | instead of hard-coding a list of MathML elements |
| 09:54 | Charl | (n=charlvn⊙cwicz) Quit () |
| 10:02 | <jgraham> | hsivonen:That sounds more sensible to me. But I think there will be some stiff opposition |
| 10:02 | webben | looks at the mailing list. Sees people /still/ trying to work out a way of making documents validate as XML and HTML. Sighs. |
| 10:37 | <Lachy> | hsivonen, I don't think that's what Sam is going to suggest. I think it's going to be about allowing xmlns attributes, but not xmlns:foo because he explicitly said no prefixes |
| 10:46 | <Charl> | ok whatbot seems to be behaving well, the stats work nicely |
| 10:46 | <Charl> | should i update the irc wiki page? |
| 10:47 | <Lachy> | Charl, yes |
| 10:48 | <annevk> | "appease the XML gods" fools! |
| 10:48 | annevk | goes back to reading the log |
| 10:58 | <annevk> | hsivonen, you want to intertwine HTML with Math in some cases... |
| 10:59 | <hsivonen> | annevk: without <math> or <html> wrapper roots? |
| 10:59 | <hsivonen> | annevk: is that case common enough that it needs to be supported in text/html? |
| 11:00 | <annevk> | it might be |
| 11:00 | <annevk> | for <svg> certainly |
| 11:00 | <annevk> | you want <foreignObject><p>TEST</p></foreignObject> as well... |
| 11:00 | <Lachy> | if any form of namespace syntax is ever going to get added to HTML, it must not use the xmlns attribute |
| 11:01 | <Lachy> | that would only serve to further convince the XML camp that HTML is compatible with XML |
| 11:03 | <annevk> | Lets not waste our time on this... Did you get any further with the parser? |
| 11:04 | <Lachy> | annevk, <foreignObject><p ns="xhtml">TEST</p></foreignObject> would be the only type of namespacing I'd support, where the ns attribute would take one of a predefined set. That way, it can't get confused with xmlns and it's not compatible xml parsing |
| 11:04 | <Lachy> | that's just an idea though, which I got from http://ln.hixie.ch/?start=1151612438&count=1 |
| 11:05 | <Lachy> | I've been reading through the Dive Into Python tutorial today, up to chapter 3 so far. |
| 11:07 | <annevk> | did you see the link I gave? |
| 11:07 | <annevk> | it shows a simple example of invoking various functions based on the state |
| 11:07 | <Lachy> | the one about constants? |
| 11:07 | <annevk> | no, the one on diveintopython |
| 11:08 | <annevk> | so you don't need a long switch case statement |
| 11:08 | <Lachy> | oh, yes, but I didn't understand the syntax well enough at the time. I'll rearead it now that I have a better idea |
| 11:09 | <annevk> | "test %s" % foo |
| 11:09 | <annevk> | replaces the %s with whatever value foo might have |
| 11:09 | <annevk> | you can also have tuples there... |
| 11:09 | <annevk> | "%stest%s" % (foo, bar) |
| 11:10 | <Lachy> | yes, that's the section I've just been reading up on in the last half hour |
| 11:12 | <Lachy> | so, basically, in principle, it's like what I was doing with the associative array of functions, where I dynamically call it based on the value of a variable |
| 11:12 | <annevk> | "This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it." |
| 11:12 | <annevk> | lol |
| 11:13 | <annevk> | Lachy, yeah, although I suppose the states would have to be strings in order to get meaningfull function invocations |
| 11:14 | <Lachy> | yes, so we can most likely use that method for what we need |
| 11:14 | mpt | (n=mpt⊙1dtn) Quit ("This computer has gone to sleep") |
| 11:17 | <Lachy> | This looks like a very convenient way of declaring constants http://diveintopython.org/native_data_types/declaring_variables.html#odbchelper.multiassign.range |
| 11:28 | <annevk> | http://www-xray.ast.cam.ac.uk/~jgraham/html5/ has some code |
| 11:28 | <annevk> | that's cool |
| 11:28 | <annevk> | hsivonen, yeah, I know what browsers do when they encounter a doctype |
| 11:29 | <annevk> | hsivonen, in gecko you can see it in the dom viewer quite easily iirc |
| 11:29 | <annevk> | I suppose it's prolly better if Opera throws for the entity &test; so we can remove some DOM Core features |
| 11:30 | <annevk> | BTW, regarding the XOM/DOM thing |
| 11:30 | <annevk> | I think we should whatever makes most sense for Python |
| 11:31 | <Lachy> | yes |
| 11:33 | <hsivonen> | annevk: that would most likely be ElementTree |
| 11:34 | <hsivonen> | disclaimers about my lack of experience apply |
| 11:34 | <hsivonen> | Kid templating uses ElementTree |
| 11:35 | <annevk> | yeah, perhaps |
| 11:35 | <ROBOd> | good eday to all! |
| 11:35 | <ROBOd> | i see that Hixie accepted Sam's proposal. well done |
| 11:35 | <hsivonen> | ROBOd: gday |
| 11:35 | <annevk> | Hixie just has a lack of faith |
| 11:36 | <ROBOd> | annevk: what do you mean? why lack of faith? |
| 11:36 | <annevk> | hsivonen, ElementTree doesn't have support namespaces ?! |
| 11:37 | <hsivonen> | annevk: really? not good! |
| 11:37 | annevk | reads http://effbot.org/zone/element.htm |
| 11:37 | <ROBOd> | i was just reading now http://blog.whatwg.org/html-vs-xhtml < this should be "featured" in the FAQ - it's important reading for everyone interested of HTML5 |
| 11:38 | <Lachy> | yes, it will be eventually. I'll just add a link to it for now |
| 11:39 | <hsivonen> | annevk: I believe ElementTree handles namespaces the RDF way |
| 11:39 | <ROBOd> | Lachy: very good article |
| 11:39 | <hsivonen> | that is nsuri#localName in one string |
| 11:39 | <Lachy> | thanks :-) (though hsivonen deserves some credit too) |
| 11:40 | <annevk> | hsivonen, that's not really acceptable |
| 11:40 | <hsivonen> | annevk: why not? |
| 11:40 | <annevk> | i don't like that |
| 11:40 | <Lachy> | what's the RDF way? |
| 11:41 | <annevk> | it requires knowledge of the namespaces that are available |
| 11:41 | <hsivonen> | annevk: because you hate RDF? It is easier than passing around (nsuri, localName) |
| 11:41 | <hsivonen> | annevk: huh? |
| 11:41 | <hsivonen> | how do you mean available? |
| 11:41 | <annevk> | used |
| 11:42 | <hsivonen> | I don't follew |
| 11:42 | <hsivonen> | follow |
| 11:42 | <annevk> | http://example.org/#foo |
| 11:42 | <annevk> | http://example.org/##foo |
| 11:43 | <annevk> | and it requires additional functions to get the localname or namespace |
| 11:43 | <hsivonen> | annevk: why don't you dispatch on the full name? |
| 11:43 | <annevk> | anyway, It's prolly not really worth it to discuss this now |
| 11:45 | <annevk> | it also seems you can't use it for XML then since it doesn't support qnames |
| 11:45 | <annevk> | and adding those would not make it look pretty |
| 11:45 | <hsivonen> | annevk: if you need to know the qName, you have a bug |
| 11:45 | <annevk> | XPath? |
| 11:46 | <hsivonen> | XPath matches on the uri, localName pair, I believe |
| 11:46 | Charl | (n=charlvn⊙cwicz) Quit (Client Quit) |
| 11:46 | <annevk> | XPath uses qnames... |
| 11:46 | <Lachy> | you only need to know the qname when serialising as XML, but when reserialising from HTML, there won't be any prefixes |
| 11:46 | <annevk> | sure |
| 11:47 | <hsivonen> | annevk: I use different qNames in XPath and in the documents that I match. matching happens on nsuri, localName |
| 11:48 | <annevk> | there has to be a reason c14n can't normalize to something without changing the qnames |
| 11:49 | <hsivonen> | without? |
| 11:49 | <annevk> | http://www.snellspace.com/wp/?p=546#comment-4751 |
| 11:49 | <webben> | amara and 4suite support namespaces |
| 11:49 | <annevk> | hsivonen, yes |
| 11:49 | <webben> | (and just because I'm too stupid to get them to work doesn't mean you guys won't be able to :) ) |
| 11:49 | <annevk> | euh, no |
| 11:49 | annevk | is confused now |
| 11:50 | <hsivonen> | annevk: I don't see the relevance of the URL |
| 11:50 | <annevk> | did I mention already this shouldn't be discussed now? |
| 11:50 | <hsivonen> | fine |
| 11:50 | <annevk> | hsivonen, that URL is totally unrelated |
| 11:50 | <annevk> | it mentions that Wordpress is borked |
| 11:50 | <annevk> | comment 1 |
| 11:50 | <hsivonen> | not news :-) |
| 11:50 | <webben> | dog bites man |
| 11:51 | <annevk> | hmm, that's a show in the Netherlands... |
| 11:51 | <annevk> | actually |
| 11:51 | <annevk> | the show is called man bites dog |
| 11:51 | <annevk> | nm me |
| 11:53 | annevk | goes to fetch some lunch |
| 11:54 | webben | (n=benjamin⊙9822) Quit ("Leaving") |
| 12:23 | Kanashii | (n=Kanashii⊙plbion) Quit () |
| 12:27 | <annevk> | so the tokenizer http://www-xray.ast.cam.ac.uk/~jgraham/html5/tokeniser.py from jgraham uses the classes construct I proposed earlier. but we figured out that it would never work because the parser and tokenizer need to be integrated |
| 12:27 | <annevk> | I suppose one could be a subclass of the other, but I'm not sure if that's worth it |
| 12:38 | <Lachy> | you mean the tokeniser and tree builder need to be integrated? |
| 12:39 | <Lachy> | we only need them to be integrated in a way that allows the tree builder to update the content model flag, I think |
| 12:40 | <annevk> | also for things like document.write I suppose |
| 12:40 | <annevk> | if ever |
| 12:40 | <Lachy> | I had a thought about that, but haven't investigated it yet, but when we call e.g. tree.startElement(), we could have the return value indicate the content model flag. Not sure if that would work or not |
| 12:40 | <Lachy> | we're not writing a scripting engine yet, we don't need to worry about doc.write() |
| 12:40 | <annevk> | we should at least take innerHTML into account |
| 12:41 | <annevk> | that's used for some conformance criteria even |
| 12:41 | <annevk> | and it's a nice way to provide serialized versions of the document |
| 12:44 | <Lachy> | to support document.write(), we need to allow a scripting engine to inject markup back into the stream. |
| 12:44 | <Lachy> | innerHTML is different though |
| 12:47 | Lachy | looks up innerHTML to see what it would take to support it |
| 12:49 | <hsivonen> | annevk: do you mean you want to allow Python apps to call innerHTML on your tree? |
| 12:49 | <annevk> | yes |
| 12:49 | <annevk> | either on a document node or element node |
| 12:50 | <annevk> | there needs to be a way to go from the tree to a string again |
| 12:52 | <hsivonen> | annevk: shouldn't you use a full-document serializer for that? |
| 12:52 | <Lachy> | yes, we should |
| 12:53 | <Lachy> | innerHTML would be nice, but we don't need to worry about it until we start implementing the DOM API. The tokeniser will work with innerHTML similar to the way it parses anything else (except for a few special things, like setting the content model flag) |
| 12:53 | <Lachy> | that's for setting innerHTML, btw |
| 12:55 | <Lachy> | on getting, we'd need to have a serialiser that it can make use of |
| 12:55 | <annevk> | hsivonen, as long as it's compatible with innerHTML... sure |
| 12:55 | <annevk> | innerHTML is the serializer we need |
| 12:55 | <annevk> | I'm not sure why anything else would be relevant, but perhaps I'm just misunderstanding what you guys are suggesting |
| 12:55 | <Lachy> | innerHTML is just an API that accesses the serialiser |
| 12:58 | <hsivonen> | perhaps Hixie already specced innerHTML on the document node to do what I want a full-doc serializer to do |
| 12:58 | <annevk> | I think so |
| 12:59 | <annevk> | otherwise my suggestion wouldn't make sense |
| 13:00 | <Lachy> | annevk, see http://www.xom.nu/apidocs/nu/xom/canonical/Canonicalizer.html |
| 13:00 | <Lachy> | the write() method gets passed a Node, which then serialises that node |
| 13:01 | <Lachy> | innerHTML just access such an API by passing it a reference to the node upon which it was invoked |
| 13:02 | <Lachy> | in XOM, the Document is a Node as well, so the write() function accepts either elements or Document |
| 13:08 | <annevk> | fair enough, Node.innerHTML |
| 13:10 | <annevk> | WhatBot, pointer? |
| 13:10 | <annevk> | WhatBot, help |
| 13:11 | <annevk> | WhatBot, you're not silly at all! |
| 13:15 | Kanashii | (n=Kanashii⊙plbion) Quit () |
| 13:25 | <Lachy> | annevk, http://lachy.id.au/temp/HTMLReader.py |
| 13:26 | <annevk> | I think you want the states as strings... |
| 13:26 | <Lachy> | there are some nice features in jgraham's parser that we should copy across, though all the DOM stuff in his parser.py shouldn't be in the parser |
| 13:27 | <annevk> | jgraham has things like "DATA":self.dataState |
| 13:27 | <Lachy> | yeah, we probably do, although I like what jgraham did in tokeniser.py with the states dictionary |
| 13:27 | <annevk> | I couldn't get that to work |
| 13:27 | <annevk> | though |
| 13:27 | <annevk> | it says that self is not defined |
| 13:27 | <annevk> | perhaps it should happen when you initialize the object |
| 13:28 | <Lachy> | is self equivalent to this in other languages? |
| 13:28 | <annevk> | yup |
| 13:28 | <annevk> | that works |
| 13:29 | <annevk> | Lachy, please join #whatwg-paste |
| 13:36 | <annevk> | Lachy, so what does XMLReader do? |
| 13:36 | <annevk> | Lachy, does it output a tree or just startDocument etc. ? |
| 13:40 | <Lachy> | when you create an XMLReader, you need to set various handlers. e.g. setContentHandler(handler) |
| 13:41 | <Lachy> | The content handler needs to implement this interface http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html |
| 13:41 | <Lachy> | as the XMLReader parses the document, it emits events by calling contentHandler.xxx(), where xxx is the appropriate method. |
| 13:42 | <Lachy> | it calls contentHandler.startDocument() first, then contentHandler.startElement(...) for every start tag, etc. |
| 13:43 | <annevk> | kk |
| 13:43 | <annevk> | I like the idea of having HTMLParser on top of HTMLReader and try to work with callback functions if that's feasible |
| 13:45 | <Lachy> | I don't understand what you mean. HTMLParser and HTMLReader are just different names for the tokeniser, aren't they? |
| 13:45 | <annevk> | the former would do tree construction and use HTMLReader as baseclass |
| 13:49 | <Lachy> | http://lachy.id.au/temp/source/ specifically, see parse.php and XMLParser.php |
| 13:50 | <hsivonen> | http://hsivonen.iki.fi/code/api/fi/iki/hsivonen/xml/checker/table/package-summary.html |
| 13:50 | <hsivonen> | in case anyone is interested in taking a look at the table integrity checker internal |
| 13:51 | <hsivonen> | s |
| 13:51 | <hsivonen> | the javadoc links to HTMLified source |
| 13:53 | <jgraham_> | So, according to thee logs, Anne said <annevk> so the tokenizer http://www-xray.ast.cam.ac.uk/~jgraham/html5/tokeniser.py from jgraham uses the classes construct I proposed earlier. but we figured out that it would never work because the parser and tokenizer need to be integrated |
| 13:54 | <jgraham_> | Is it not enough just to have the parser hold a ref to the tokeniser so it can adjust its state? Does it need to do more than change the content model flag? |
| 13:55 | <jgraham_> | (Oh and I know the DOM stuff needs to be (re)moved, that was just a really basic tree implementation to get me going). I was wondering about using elementtree |
| 13:56 | <Lachy> | jgraham, I don't understand why you have classes for each token. Do you create a token object for each one and emit that? |
| 13:56 | <annevk> | jgraham, well yeah, but then you don't need classes for tokens anymore |
| 13:56 | <annevk> | jgraham_, you construct the "DOM stuff" right away |
| 13:57 | <jgraham_> | Yeah. One class per token type. It just seemed conceptually simple. |
| 13:57 | <annevk> | but those token types don't survive for a second... :) |
| 13:58 | <Lachy> | ok. looking back at the JS implmentation I started a few months ago, it looks similar to what I was trying to do as well. But I prefer to just use SAX-like events instead of creating a token object |
| 13:59 | <jgraham_> | Maybe I haven't read the spec closely enough... why do they need to survive? Or are you just worried that it means creating and destroying a lot of objects? |
| 14:00 | <Lachy> | well, yeah, sort of. It just seems unnecessary to create, say, a StartTag token, when you can just call handler.startElement(...) |
| 14:03 | <jgraham_> | Well sometimes you need to keep tokens around for a little while (e.g. when you want to reprocess the current token). Also, the tokeniser seems to create a stack of tokens in some instances... |
| 14:03 | jgraham_ | hasn't looked at the tokeniser for a little while |
| 14:05 | <Lachy> | neither have I, I need to reread that part of the spec and also improve my knowledge of python |
| 14:09 | <jgraham_> | I think elementtree output would be nice but it's pretty different from the standard DOM |
| 14:11 | <jgraham_> | apart from the think where namespaces are stored as "{nsURI}localName", you'd have to deal with the different way of storing text |
| 14:12 | <jgraham_> | e.g. <span>foo <em>bar</em> baz</span> has " baz" in the tail attribute of the em element... |
| 14:12 | <annevk> | ? |
| 14:14 | <annevk> | oh, they store text that way? |
| 14:15 | <annevk> | that sounds rather bad |
| 14:15 | <jgraham_> | iir correctly the sample above has Span.text="foo " Em.text="bar" Em.tail=" baz" - tail holds all the text after the element closes but before the next sibling opens or parent closes |
| 14:15 | <Lachy> | jgraham, wow. that's really bad |
| 14:16 | <jgraham_> | It often works quite well, actually. But less so for prose-orientated documents |
| 14:16 | <Lachy> | well, unless .tail is just the equivalent of .nextSibling in the DOM |
| 14:16 | <Lachy> | does the parent element still have refences to all of its child nodes? |
| 14:17 | <jgraham_> | I don't think it really considers text as nodes in the tree, just attributes of elements |
| 14:17 | <jgraham_> | or attributes of nodes, if you like |
| 14:17 | <Lachy> | oh, that's crap |
| 14:18 | <jgraham_> | Well like I sid, it works really nicely in python in practice, but it's not trivial to map onto the DOM model |
| 14:25 | <jgraham_> | annevk: the reason that you couldn't get the "DATA":self.dataState thing to work is because it doesn't. I don't quite know what I had in my head (I've been using this pattern quite a bit in the code). |
| 14:25 | <jgraham_> | I'm pretty sure I can fix it up so it does work though :) |
| 14:28 | <annevk> | jgraham_, I made it work... |
| 14:28 | <annevk> | jgraham_, put the states in __init__ |
| 14:29 | <jgraham_> | Yeah, I that will work, obviously. I had it in my head you could avoid that somehow though. Maybe I'm imagining things ;) |
| 15:08 | Charl | (n=charlvn⊙nmcz) Quit () |
| 15:25 | jgraham_ | (n=jgraham⊙xacau) Quit ("Leaving") |
| 15:29 | <Lachy> | I've added a new question about treating HTML as XML to the FAQ |
| 15:29 | <Lachy> | http://blog.whatwg.org/faq/ (see the last question) |
| 15:30 | <Lachy> | any suggestions for improving it would be appreciated |
| 15:41 | <annevk> | do not |
| 15:42 | <Lachy> | annevk, do not what? |
| 15:42 | <annevk> | you forgot not in your last e-mail |
| 15:43 | <Lachy> | where abouts. Can you quote the sentence where I made the mistake? |
| 15:44 | <annevk> | not anymore |
| 15:44 | Lachy | is confused |
| 16:13 | <annevk> | Charl, cool bot |
| 16:13 | <annevk> | Lachy, I removed the e-mail |
| 16:14 | <Lachy> | what e-mail? |
| 16:14 | <annevk> | see above |
| 16:14 | <Lachy> | ? |
| 16:14 | <annevk> | ?? |
| 16:15 | <annevk> | a: you forgot not in your last e-mail |
| 16:15 | <annevk> | l: where abouts. Can you quote the sentence where I made the mistake? |
| 16:15 | <annevk> | a: not anymore |
| 16:15 | <Lachy> | which e-mail are you referring to? |
| 16:15 | <Lachy> | yeah, I have no idea what you meant by that |
| 16:15 | <annevk> | I said not anymore because I removed the e-mail... |
| 16:15 | <Lachy> | from where? |
| 16:15 | <annevk> | inbox |
| 16:16 | <annevk> | dude! |
| 16:16 | <Lachy> | right, so one of the e-mails I setnt to whatwg? |
| 16:17 | <annevk> | the last one |
| 16:18 | <Lachy> | oh, I see "I really do [not] understand the desire to do so." |
| 16:22 | <Charl> | annevk: thanks, i think whatbot is doing well for its first day :) (sorry for slow reply, hacking code..) |
| 16:34 | <Hixie> | for those of you writing a tokeniser in python, my guess would be that the easiet implementation would use "yield" |
| 16:34 | <Hixie> | since then you never have to unwind the tokeniser stack |
| 16:35 | <Lachy> | wjat |
| 16:35 | <Lachy> | what's yeild |
| 16:36 | <Lachy> | do you mean this http://docs.python.org/ref/yield.html |
| 16:37 | <Hixie> | yes |
| 16:39 | <annevk> | yeah, I suppose that makes sense |
| 16:40 | <Hixie> | though fwiw, i don't think my tokeniser ever has to emit more than two tokens at once, so i just have two tokens, "current" and "next" |
| 16:42 | <Lachy> | I'm trying to find an example that shows how to use it, and which explains it more clearly than that documentation |
| 16:44 | ROBOd | (n=robod⊙8321) Quit ("http://www.robodesign.ro";) |
| 16:45 | <annevk> | surch for generators and python |
| 16:45 | <annevk> | or something |
| 16:47 | annevk | has to go change for the Opera Christmas party |
| 16:48 | annevk | is prolly online again tomorrow |
| 16:48 | <Lachy> | ok, I've found an example and sort of understand it now |
| 16:50 | <Lachy> | so would we use that to iterate through each character in the file stream? or something else? |
| 17:01 | <Lachy> | Hixie, could you perhaps add a note to the spec in the start tag syntax section pointing out the use of the trailing slash does not permit the use of an XML parser to parse and HTML document and link to the parsing section where it defines that? |
| 17:02 | <Hixie> | nah |
| 17:03 | <Hixie> | i don't think that would help anyone |
| 17:03 | <Lachy> | ok, it's just that all these people with the idea that they can do so is just irritating |
| 17:03 | <Hixie> | for someone to be reading that part of the spec, they have to either have read the relevant part that says it's not XML, or they'll miss the note in the same way |
| 17:03 | <Hixie> | yeah, i agree |
| 17:08 | <raspberry-lemon> | why was the trailing slash thing added? |
| 17:09 | <Hixie> | to make it easier for authors to migrate from XHTML |
| 17:09 | <raspberry-lemon> | ah |
| 17:09 | <Hixie> | and because trailing slashes have this "designer label" quality these days |
| 17:09 | <Hixie> | basically |
| 17:09 | <raspberry-lemon> | yeah |
| 17:10 | <Hixie> | Lachy: i updated the spec's way of having spaces in start attributes. it's not what you proposed, but i think it's ok. (basically i added more steps and modified the attribute syntax section) |
| 17:12 | <Lachy> | I think the discussion on the list is showing that people going to consider it an Appendix-C-like extension designed as a means to help them continue migrating from HTML to XHTML, rather than from XHTML1 to HTML5 |
| 17:12 | <Hixie> | possible |
| 17:12 | <Hixie> | they'll be sadly mistaken :-) |
| 17:13 | <Lachy> | I'm writing an FAQ entry for it now. I'll include those reason in it. |
| 17:13 | <Hixie> | cool |
| 17:13 | <Hixie> | Charl: yt? |
| 17:14 | <Charl> | Hixie: hi am here now |
| 17:14 | <Hixie> | Charl: hey dude |
| 17:14 | <Hixie> | so i was thinking about the status thing |
| 17:14 | <Charl> | yeah, let's get that going |
| 17:14 | <Hixie> | i think it would make sense to also have the "SCS" flags as part of it |
| 17:15 | <Hixie> | to mark which sections are "self-contained" |
| 17:15 | <Hixie> | so that they can be implemented separately |
| 17:15 | <Hixie> | that way i can remove the SCS stuff from the spec :-) |
| 17:15 | <Charl> | ah, that sounds interesting |
| 17:15 | <gsnedders> | Lachy: I'll send you an update to that PCRE, as I realised several bugs in it a day or two ago |
| 17:16 | <Lachy> | don't worry about it |
| 17:16 | <Lachy> | we're not going to implement it |
| 17:16 | <Charl> | Hixie: since that's already there, i think i should start by getting the script to be able to insert those |
| 17:17 | <Charl> | Hixie: am going to be offline during the weekend unfortunately - is it ok if i speak to you about that on Monday? |
| 17:17 | <Lachy> | Once hsivonen updates the validator so the trailing slash isn't flagged as an error, I'll just remove the script and accept that WP is a broken CMS |
| 17:18 | <Hixie> | Charl: sure thing dude. |
| 17:18 | <Hixie> | Charl: there's no rush really. |
| 17:19 | <Hixie> | Charl: though it would be nice to have it up and running by the end of the year, since i expect the w3c to start moving faster in january |
| 17:19 | <Charl> | Hixie: cool, we'll get it sorted long before then :) |
| 17:19 | <Hixie> | :-) |
| 17:19 | <Lachy> | Hixie, has any progress been made on the charter since that first draft? |
| 17:20 | <Hixie> | Lachy: i've been told so, but i haven't seen it or heard anything but rumours |
| 17:20 | <Lachy> | ok. |
| 17:20 | <Hixie> | Lachy: i highly doubt the progress will be enough to make the whatwg move lock-stock-and-barrel to w3c |
| 17:20 | <Hixie> | basically i intend to continue the whatwg work unless the w3c provides a community environment as open as the whatwg |
| 17:21 | <Hixie> | which i don't see happening, they just don't understand openness, sadly |
| 17:21 | <Lachy> | ok, good |
| 17:21 | <Lachy> | well, good that you'll continue, bad that they don't understand opennes :-( |
| 17:21 | <Hixie> | yeah |
| 17:22 | <Lachy> | I think the start tag syntax still needs to be made a little clearer |
| 17:22 | <webben> | Presumably it doesn't need to be a total dichotomy. |
| 17:22 | <webben> | That is the W3C actually has submissions from outside all the time. |
| 17:23 | <Hixie> | webben: oh i'll be in their htmlwg either way |
| 17:23 | <webben> | All the W3C really needs to do is not try and reinvent Web Forms 2.0 with yet-another-intermediate technology. |
| 17:23 | <Hixie> | or not change wf2 in stupid ways |
| 17:23 | <webben> | And all WHATWG really needs to do is not to let too big a gap grow between XHTML 5 and the rest of the XML world. |
| 17:23 | <Lachy> | Perhaps you could add something to setp 5 that explicitly refers the additional requirements for unquoted attribute values and empty attributes |
| 17:24 | <webben> | There's no particular reasons why all specs should be developed in-house as it were |
| 17:24 | <Hixie> | webben: we'll see |
| 17:25 | <Lachy> | if browser vendors just don't implement their corrupted version of WF2+XForms (if they go ahead with it), won't that just make it irrelevant like XHTML2? |
| 17:25 | <Hixie> | yup.... |
| 17:26 | <Hixie> | Lachy: spec updated |
| 17:26 | <Lachy> | so does it really matter in the end, as long as it keeps the XForms people away from the real spec, they can play with their own version as much as they like |
| 17:27 | <Lachy> | that's good now :-) |
| 17:27 | <webben> | Of course it matters. Because that scenario would be a waste of the W3C's time. |
| 17:28 | <webben> | (which, given they're slow, short of staff, and short of money, is precious) |
| 17:28 | <webben> | Maybe what's really needed is a demonstration of alternate serialization to WF2 and XForms |
| 17:29 | <webben> | That would probably get IBM on board. |
| 17:29 | <webben> | (AFAICT they seem to be a key opponent of WF2 in its current form) |
| 17:29 | <webben> | Is such serialization currently possible, or would it be very difficult? |
| 17:30 | <Hixie> | IBM is a large company with many employees |
| 17:30 | <Hixie> | they don't always agree |
| 17:30 | <webben> | hmm... okay s/IBM/the IBM XForms guys/g |
| 17:34 | <Hixie> | heh |
| 17:35 | <Lachy> | "However, a start tag must never be omitted if it has any attributes." What if it has attributes, but which are explicitly set to the default values? |
| 17:35 | <Hixie> | then it has attributes, and mustn't be omitted |
| 17:36 | <Lachy> | oh, nevermind, I just realised that it does make a difference to the DOM if they're omitted |
| 17:36 | <Hixie> | what is WITH people and xmL:id |
| 17:37 | Lachy | looks for e-mail referring to xml:id... |
| 17:37 | <Hixie> | michel's recent one |
| 17:37 | <Hixie> | michel's a great guy btw |
| 17:37 | <Hixie> | been sending great feedback |
| 17:40 | <Lachy> | yeah, he's ok. he's not one of the "kooks" :-) |
| 17:42 | <hsivonen> | IIRC, anne likes xml:id. or at least used to like ;-) |
| 17:46 | <Lachy> | Hixie, xml:id is already mentioned in the spec |
| 17:47 | <Hixie> | crap |
| 17:48 | <Hixie> | better take that out |
| 17:48 | <Hixie> | :-) |
| 17:48 | <Lachy> | only twice, though |
| 17:48 | <Hixie> | oh it's just as parantheticals |
| 17:48 | <Hixie> | that's ok |
| 17:48 | <Hixie> | jesus, annevk needs to work on his tact |
| 17:49 | <Hixie> | "You're still not getting it, do you?" sounds like the kind of thing i would write when i was his age, which is why the w3c staff all hate me now. :-P |
| 17:51 | <Lachy> | heh |
| 17:54 | <hsivonen> | BTW, I think there's a right reason and a wrong reason for wanting the intersection of HTML5 and XHTML5 syntaxes not to be empty |
| 17:54 | <hsivonen> | the right reason is Sam's reason: being able to use one code path for *producing* both |
| 17:55 | <hsivonen> | the wrong reason is being supposedly able to use one code path for *consuming* both |
| 17:55 | <Hixie> | you can do sam's thing with just minor things in the header |
| 17:55 | <Hixie> | if you avoid troublesome things like xml:base, xml:lang/lang, <noscript> |
| 17:55 | <Hixie> | document.write |
| 17:56 | <Hixie> | .tagName |
| 17:56 | <Hixie> | etc |
| 17:56 | <Lachy> | the problem with that "right reason", though, is that has proven fatal with all the people failing to produce XHTML 1.0 properly as text/html. |
| 17:56 | <hsivonen> | like I said on the list, the problem with Sam's case is the "professional driver on closed road thing": those who imitate him can and will get confused and break stuff |
| 17:57 | <Hixie> | yup |
| 17:57 | <hsivonen> | s/ thing"/" thing/ |
| 17:57 | <Lachy> | If people wish to use the one code path to develop both, they need to write in one syntax and use a program to serialise to the other |
| 17:57 | <Hixie> | yup |
| 17:57 | <Hixie> | i think we're close enough to allowing #1 to not need to go any further |
| 17:58 | <Lachy> | agreed |
| 17:58 | <Lachy> | the sooner we can get some tools made available that do actually transform one serialisation into the other, the sooner people might actually start to understand the whole concept |
| 18:10 | <webben> | Hixie, what is a "code path"? |
| 18:11 | <webben> | Hixie, is this a really complicated way of saying you need to be able to serialize both from the same source? |
| 18:12 | <webben> | or more than that...? |
| 18:14 | <Lachy> | webben, it's just a way of saying the way in which you write your code. So if you want to follow one code path to write both HTML and XHTML, they either have to be the same syntax or be easy to transform from one to the other. |
| 18:14 | <webben> | How many cases are there currently (if any) where XHTML5 can fully represent an idea that HTML5 cannot? |
| 18:15 | <webben> | (excluding pulling in stuff from other namespaces) |
| 18:15 | <Lachy> | <p><ul>...</ul></p> is one |
| 18:15 | <webben> | ah ... what about <p><blockquote>...</blockquote></p>? |
| 18:16 | <Lachy> | same for <ol>, and other structured inline-level elements |
| 18:16 | <Hixie> | a "code path" is a set of steps through some code. so e.g. the program: if (a) { doA(); } else { doB(); } has two codepaths, one for if a is true, and one for if it is false. |
| 18:16 | <Lachy> | http://whatwg.org/specs/web-apps/current-work/#structured |
| 18:17 | Hixie | wonders where he used the term "code path" |
| 18:17 | webben | doesn't quite understand. Surely you'd only ever want to produce XHTML5 /or/ HTML5 as one or another code path. |
| 18:17 | <webben> | e.g. if ancient user ancient, produce HTML5 and if new user agent produce XHTML5 |
| 18:17 | <Hixie> | webben: some people want to send XHTML to mozilla and HTML to IE |
| 18:18 | <Hixie> | but they don't want to write their code twice |
| 18:18 | rhymes | (n=rhymes⊙h5rti) Quit () |
| 18:18 | <Hixie> | they want to have most of the code be the same for both |
| 18:18 | <Hixie> | in totally unrelated news, why did PG&E (the electric company) just randomly give me $90 this month. wtf. |
| 18:18 | <webben> | heh count your blessings :) |
| 18:18 | <Hixie> | oh i'm not complaining |
| 18:19 | <Lachy> | PG&E? |
| 18:19 | <webben> | Could we counter the <p> problem by introducing an equivalent alternative e.g. <para> ? |
| 18:19 | <Lachy> | ah Pacific Gas and Electric |
| 18:19 | <Hixie> | problem? |
| 18:20 | <webben> | problem == something you can do in XHTML5 not HTML5 hence making more code paths |
| 18:20 | <Lachy> | no, that wouldn't work |
| 18:20 | <webben> | Lachy, why? |
| 18:20 | <Lachy> | it would be treated like any unknown element and isn't backwards compatible |
| 18:21 | <webben> | hmm ... how about a microformat class="para" applied to div ? |
| 18:21 | <Lachy> | and authors wouldn't use it |
| 18:21 | <Lachy> | no |
| 18:21 | <Lachy> | <p> is for paragraph |
| 18:21 | <Lachy> | not div or any other element |
| 18:21 | <webben> | but then paragraph means something different in XHTML5 from HTML5. |
| 18:21 | <webben> | paragraph in HTML5 actually means "block of text" |
| 18:22 | <webben> | (like in HTML4) |
| 18:22 | <Lachy> | no, it means the same thing. The difference is that, for backwards compat reasons, the HTML serialisation can't produce the same result as the XML serialisation in some cases |
| 18:22 | <webben> | So what would a CMS do then? Throw up an error? |
| 18:23 | <Lachy> | the same is true for <noscript> in the other direction. i.e. it can be represented in HTML, but not in XHTML |
| 18:23 | <Lachy> | an error for what? |
| 18:23 | <webben> | Lachy, yeah but <noscript> is semantically unimportant |
| 18:23 | <Hixie> | webben: it just means that for certain things, the CMS shouldn't allow it if it is ever going to serialise to HTML form |
| 18:23 | <webben> | Lachy, that's just code stuff ... no relation to real-world ideas like paragraphs |
| 18:26 | <webben> | <p>foo<blockquote><p>foo</p></blockquote></p> is okay in HTML5 isn't it? |
| 18:26 | <Lachy> | Hixie, in those cases, it just makes the HTML serialisation a slightly lower quality alternative than the original XML serialisation. A CMS shouldn't prevent it from occurring, though it may choose to warn the user |
| 18:27 | <Lachy> | s/user/author |
| 18:27 | <Hixie> | fair enough |
| 18:28 | <Hixie> | webben: yes |
| 18:30 | <webben> | but <p><blockquote><p>foo</p></blockquote></p> would be wrong ... is that right? |
| 18:30 | <Hixie> | no that's allowed too |
| 18:31 | <Hixie> | somewhat pointless, but allowed |
| 18:31 | webben | is now confused |
| 18:31 | <webben> | (again) ;) |
| 18:31 | <Hixie> | Lachy: pick a TBW section for me to work on next :-) |
| 18:31 | <webben> | what would I need to do to my blockquote example to break it? |
| 18:31 | Hixie | has run out of things on his 2006Q4 todo list for HTML5 :-/ |
| 18:31 | <Hixie> | webben: something like: |
| 18:31 | <Hixie> | um |
| 18:32 | <Hixie> | <ol> <li> foo <blockquote> ... would be illegal |
| 18:32 | <Hixie> | <ol> <li> <p> foo </p> <blockquote> ... would be fine |
| 18:32 | <Hixie> | <ol> <li> <p> foo <blockquote> ... would be fine too |
| 18:32 | <Hixie> | no wait |
| 18:32 | <Hixie> | la la la |
| 18:32 | <Hixie> | that's all wrong |
| 18:32 | <Hixie> | try again |
| 18:33 | <webben> | isn't the first example legal even in HTML4? |
| 18:33 | <Hixie> | "<aside> foo <p>..." would be illegal |
| 18:33 | <Hixie> | not everything allowed by HTML4 is allowed in HTML5 |
| 18:33 | <Hixie> | especially when it comes to elemenst that in HTML4 had the content model %flow |
| 18:33 | <Hixie> | html5 is "stricter" |
| 18:34 | <Lachy> | Hixie, how about either http://www.whatwg.org/specs/web-apps/current-work/#scripting0 or http://www.whatwg.org/specs/web-apps/current-work/#classes |
| 18:34 | <Hixie> | aw man, that's like the two hardest sections! |
| 18:34 | <Hixie> | ok |
| 18:35 | <Lachy> | I thought classes would be the easiest? |
| 18:35 | <Hixie> | not sure what classes has to say |
| 18:35 | <Hixie> | that's the problem :-) |
| 18:35 | <Lachy> | but I knew scripting would be hard, though |
| 18:35 | <Hixie> | i can't require a wiki entry for every class value |
| 18:35 | <Hixie> | that would be stupid |
| 18:35 | <Hixie> | given how often people invent new ones |
| 18:35 | <Hixie> | though it would be fun to try |
| 18:36 | <webben> | Hixie, you can have a big bold thing about using structural/semantic names |
| 18:36 | <webben> | and then recommend the wiki if you want anyone else to understand those names |
| 18:36 | <webben> | (and a long spiel about avoiding classes like "red" and "nav-left" |
| 18:36 | <Lachy> | I think one of the studies of just a few hundred pages that I read revealed something like 5000 class names, from memory. I can't remember which study that was |
| 18:37 | <Lachy> | maybe I'm exagerating that number a bit though |
| 18:37 | <webben> | Lachy, dreamweaver and friends inflate these things though |
| 18:37 | <Hixie> | Lachy: yeah my own study revealed six bazillion :-P |
| 18:37 | <webben> | and class="MSWordGarbarge679970" |
| 18:38 | <Lachy> | hahahaha! |
| 18:38 | <webben> | you'd expect the set to be large, if only because of multiple languages |
| 18:38 | <Lachy> | if you want something easiser, you could try image maps |
| 18:39 | <Hixie> | nono |
| 18:39 | <Hixie> | classes is fine |
| 18:39 | <Hixie> | just not sure what to say |
| 18:39 | <webben> | Hixie, you could make some recommendations about what make good classnames from a scripting/css perspective too |
| 18:39 | <Lachy> | oh, ok |
| 18:39 | <webben> | Hixie, you need to clarify what UAs should do with classes |
| 18:39 | <Hixie> | "nothing" |
| 18:39 | <Hixie> | that's already in the spec |
| 18:39 | <Hixie> | this section would be predefined class names |
| 18:39 | <webben> | Hixie, I've been having correspondence with someone subscribed to www-html who's convinced UAs should be reading them out or something |
| 18:39 | <Hixie> | like hCard's |
| 18:40 | <Hixie> | well there are weirdos everywhere |
| 18:40 | <Hixie> | especially www-html :-P |
| 18:40 | <webben> | Hixie, I think he simply didn't realize that screen readers do nothing of the sort. |
| 18:40 | <webben> | and misunderstood the stuff about semantic class names |
| 18:40 | <Lachy> | would it be out of scope for us to take the hCard and hCalendar specs and rewrite them with actual conformance and processing requriements? |
| 18:40 | <webben> | so I think there is room for being clear |
| 18:41 | <Hixie> | you don't think http://www.whatwg.org/specs/web-apps/current-work/#metadata is clear enough? |
| 18:41 | <Hixie> | Lachy: i intend to do so eventually if nobody else does... but i don't want to, i'd like microformats.org to do it |
| 18:42 | <Lachy> | I think you'll be waiting a while for that |
| 18:42 | <webben> | Hixie, no, not really. |
| 18:42 | <Hixie> | webben: hmm, ok |
| 18:42 | <Hixie> | right, gotta go. bbl. |
| 18:42 | <Lachy> | unfortunately, very few people heavily involved with microformats actually have any experience writing good specifications. |
| 18:42 | <webben> | Hixie, although it's close |
| 18:42 | <webben> | Hixie, maybe you should just expand that a bit and link to it from #classes |
| 18:43 | <webben> | Lachy, I think that would be a good idea. |
| 18:43 | <webben> | Lachy, if you look at what XHTML2 is doing, about the only roles I have much hope for are the ones they or WAI are actually including in the spec |
| 18:43 | <webben> | if you include hcard and hcalendar UAs will be much more likely to do something useful with them |
| 18:43 | <Lachy> | are you referring to the role attribute? |
| 18:44 | <webben> | Lachy, yes |
| 18:44 | <Lachy> | oh, no. |
| 18:44 | <Lachy> | the role attribute is useless |
| 18:44 | <webben> | Lachy, I'm not sure if you're agreeing or disagreeing with me. |
| 18:45 | Lachy | is rereading what you wrote... |
| 18:45 | <webben> | As it stands as a method of extension, role suffers the same defects as class pretty much. |
| 18:45 | webben | wrote a long whinge to www-html about how underspecified the whole structure is. |
| 18:45 | <webben> | Lachy, but Mozilla, Orca, Window-Eyes, etc are implementing the WAI stuff. |
| 18:46 | <webben> | actually I wrote two long whinges, but the first one didn't accomplish anything |
| 18:46 | <Lachy> | most of the roles they're specifying in the specs are already covered by either new elements, link relationships or other semantics already in HTML5 |
| 18:47 | <webben> | Lachy, The contrast I was drawing was between stuff in the spec and stuff not in the spec. The first has much higher status. |
| 18:47 | <webben> | And that means more implementations, which in turn makes things more useful. |
| 18:47 | <Lachy> | what name do you use in your e-mails? I can't find any e-mails in my www-html archive from you |
| 18:47 | <webben> | sorry Benjamin Hawkes-Lewis |
| 18:47 | <webben> | bhawkeslewis at googlemail |
| 18:48 | <Lachy> | ah, yes, I have those |
| 18:48 | <webben> | might also be one from benjaminhawkeslewis at hotmail |
| 18:48 | <Lachy> | @googlemail.com |
| 18:48 | <webben> | that's the one |
| 18:48 | <Lachy> | is that like gmail? |
| 18:48 | <webben> | Lachy, it's what Google have to use in UK because of a trademark dispute |
| 18:48 | <webben> | if you send to bhawkeslewis at gmail.com that will reach me too |
| 18:49 | <Lachy> | tradmark with who? |
| 18:49 | <webben> | Lachy, some tiny company offering gmail ... hold on I'll dig the link |
| 18:49 | <webben> | Lachy, http://news.bbc.co.uk/1/hi/business/4354954.stm |
| 18:52 | <Lachy> | I got into a discussion about role on the w3c-wai-ig list a few weeks ago, and the conclusion I drew from that was that all the use cases and examples they have for role, with the exception of role="search" are already covered in HTML5 |
| 18:52 | <Lachy> | and role=search could be addressed by an <input type="search"> value |
| 18:54 | <webben> | Lachy, Yeah. It's really with the extension methods I'm worried about. (Especially accessibility arising there from.) |
| 18:54 | <webben> | *accessibility issues |
| 18:54 | <webben> | I have the same reservations about microformats. (I still think they're a good idea. But they worry me.) |
| 18:56 | webben | headdesks as ffmpeg fails to build yet again. |
| 18:57 | <webben> | Role /really/ worries me though. As it's become a block to adding certain semantics, yet I can't see how those semantics are going to be accessible if extended via role. |
| 18:58 | <webben> | (It's the contrast between the "add spoiler as a role" attitude of the www-html list and the actual work going into DHTML accessibility at Mozilla that draws the starkest contrast for me. |
| 19:01 | <Lachy> | the problem with extending via role is that it's done using RDF. But, as far as implementations are concerned, they're still not going to be able to do anything useful with it based on that RDF, so the RDF is effectively useless |
| 19:02 | <Lachy> | plus there's the whole namespace issue as well |
| 19:06 | <Charl> | k i need to go now - have a good weekend all!!! :) |
| 19:06 | Charl | (n=Charl⊙1211) Quit () |
| 19:07 | <webben> | Lachy, "as far as implementations are concerned, they're still not going to be able to do anything useful with it based on that RDF" ... that is /precisely/ the problem |
| 19:07 | <Lachy> | :-) |
| 19:08 | <webben> | unless they can come up with a XML description format capable of building interfaces or something it won't work |
| 19:08 | <webben> | but there doesn't seem to be any recognition of that |
| 19:09 | <webben> | (if they were sensible they might think about trying to adapt XUL or something I suppose.) |
| 19:09 | <webben> | but to work with clients varying from phones to emacs to ie |
| 19:09 | <webben> | it would probably need to be a higher-level description |
| 19:11 | <webben> | starting with some way of prioritising semantics |
| 19:16 | Lachy | finally finished getthing through all the whatwg mail |
| 19:21 | <ROBOd> | Lachy: i am also reading the whatwg emails myself ... and i just want to tell you about something you've said |
| 19:21 | <ROBOd> | "It would be theoretically possible [to parse HTML as XHTML], but totally impractical in the real world. You can do whatever you like in your own authoring environment where you have control over exactly what goes into your documents, but XML parsing for HTML on the web is totally impractical and I really do understand the desire to do so." |
| 19:22 | <ROBOd> | the sole purpose of me wanting to have the trailing slash of was for internal stuff |
| 19:23 | <ROBOd> | *not* to parse documents in the wild, on the web. in my case, it's all about internal processing on the server and validation |
| 19:24 | <ROBOd> | desiring to do XML parsing for HTML on the web is generally silly |
| 19:25 | <ROBOd> | unless two sites, for example, have precise rules over their own content - but that's completely out of reach for the spec |
| 19:28 | <webben> | ROBOd, but this is an exchange format |
| 19:28 | <Lachy> | ROBOd, but my main points are that a) The XHTML serialisation is defined for XML processing |
| 19:28 | <webben> | isn't XML better suited for behind-the-scenes processing anyhow? |
| 19:29 | <ROBOd> | webben: internally, i find it desirable to have the same code, to parse it all as XML, and to serialize it either as XHTML or HTML. |
| 19:29 | <ROBOd> | webben: exactly, all XML internally, and out ... whatever i want |
| 19:30 | <webben> | ROBOd, well people here are talking about building a working transformer |
| 19:30 | <Lachy> | b) what you do on your own system isn't really subject to interoperability contstraints and isn't really relevant and... |
| 19:30 | <webben> | I think that makes more sense than changing the spec /just/ for that |
| 19:30 | <ROBOd> | webben: i'm rather too busy to follow all of the discussion on this channel |
| 19:31 | <webben> | ROBOd, Sorry, that wasn't meant to be accusatory... just letting you know. :) |
| 19:31 | <ROBOd> | webben: oh, i know that wasn't accusatory. i was just letting you know ;). and thanks |
| 19:32 | <Lachy> | c) because of (a) there is no reason to do (b) anyway, and allowing it at all would be harmful on the web, just like allowing XHTML as text/html has been |
| 19:33 | <Lachy> | if that doesn't make sense, keep in mind that I'm getting quite tired :-) |
| 19:33 | <raspberry-lemon> | uh, which spec change are you all talking about? |
| 19:33 | <ROBOd> | Lachy: i don't think allowing XHTML as text/html has been very bad. |
| 19:33 | <Lachy> | raspberry-lemon, the trailing slash one |
| 19:33 | <webben> | raspberry-lemon, the trailing slash /> in empty elements |
| 19:33 | <raspberry-lemon> | oh yeah |
| 19:34 | raspberry-lemon | is really happy about that |
| 19:34 | <webben> | ROBOd, that's because (as far as I can understand) you're using a "what-works" model of authoring. |
| 19:34 | <Lachy> | ROBOd, it's been proven harmful in the last few days. If people never served XHTML as text/html, we would have never even been having this discussion about introducing XML syntax into HTML, despite it being completely usless |
| 19:36 | <ROBOd> | webben: not sure what you define as "what-works". i use almost-valid HTML4 Strict (no presentational tags, of course, with CSS, non intrusive JS sometimes), with trailing slashes for void elements (hence almost-valid code) |
| 19:36 | <Lachy> | if if we didn't even allow the XML syntax, people wouldn't even be able to process HTML5 as XML at all (unless they don't use void elements) |
| 19:36 | <webben> | ROBOd, Well. If it's "almost-valid" it's non-standard. So presumably your test is "does it work for my purposes in my test cases". |
| 19:36 | <Lachy> | the more I think about it, the more I'm really startin to like the idea to change the doctype to prevent XML parsing of HTML5 all together |
| 19:36 | <ROBOd> | webben: that is not exactly "what works" IMHO, since "what works" are those table-CSS sites, invalid, with XHTML DTD, served as text/html |
| 19:37 | <raspberry-lemon> | Lachy: it's not just about parsing, though |
| 19:37 | <webben> | ROBOd, Those only work in a very restricted testing environment. |
| 19:37 | <Lachy> | raspberry-lemon, what else is it about? |
| 19:37 | <raspberry-lemon> | a *lot* of the tools written during the last couple of years add trailing slashes for void elements |
| 19:37 | <webben> | They're pretty horrendous to maintain, modify, and use with alternative UAs. |
| 19:38 | <webben> | raspberry-lemon, yeah ... but those are for generating a different markup format. |
| 19:38 | <ROBOd> | webben: "Those", which? |
| 19:38 | <webben> | ROBOd, sorry "those table-CSS..." |
| 19:38 | <Lachy> | broken authoring tools can be fixed. They are not an excuse for introducing the syntax. |
| 19:39 | <ROBOd> | webben: oh ... well ... "those table-CSS" *do work* in todays modern UAs |
| 19:39 | <raspberry-lemon> | they won't be fixed, though |
| 19:39 | <Lachy> | a *lot* of tools add XHTML DOCTYPEs too, but that's not a major problem |
| 19:39 | <raspberry-lemon> | and people will be forced to use them for a long time |
| 19:39 | <webben> | ROBOd, Except they don't. Indeed, people need new tools just to get around the breakage. e.g. to linearize tables. |
| 19:40 | <ROBOd> | webben: they are patched sooo much until they work ... more or less ... as intended by the (confused) author |
| 19:40 | <webben> | ROBOd, As authors don't test with odd UAs or odd UA configurations, breakages are not notices and no fixes are made |
| 19:41 | <ROBOd> | webben: true |
| 19:41 | <Lachy> | raspberry-lemon, new tools are being developed to support HTML5 properly. There's already a validator well under development, I'm in the process of writing a CMS that will author in XHTML and serialise as HTML5, and plenty of parsers are being written |
| 19:42 | <ROBOd> | webben: nonetheless, it doesn't compare to what i do :P. i don't do ... patching ... i don't do guess work. except for the guess work I do with IE6+ CSS rendering |
| 19:42 | <webben> | ROBOd, I wasn't trying to say that your techniques were that intrinsically broken. (I wouldn't have allowed them the label "what works" if I thought that.) |
| 19:43 | <webben> | ROBOd, but I'd put all non-standards authoring in a different camp to standards-based authoring. |
| 19:43 | <webben> | non-standards authoring /can/ work in most cases ... can even be generally accessible ... I just think it's much more risky and fragile. |
| 19:44 | <ROBOd> | webben: my definition of "what works" is ... quite bad... "intrinsically broken" |
| 19:44 | <webben> | ah okay |
| 19:44 | <webben> | we're operating from slightly different definitions then :) |
| 19:44 | <ROBOd> | hehe |
| 19:45 | <ROBOd> | webben: what hsivonen has defined as bozos ... somehow is too general, IMHO |
| 19:45 | <webben> | ROBOd, I suppose what I would object to (however futilely) is your use of a doctype. |
| 19:45 | <ROBOd> | since he wants everyone to use a complete parser, serializer, server-side DOM for everything the web app outputs |
| 19:46 | <webben> | ROBOd, I think doctypes should really be approached as contracts rather than hacks to force one or another type of CSS rendering. |
| 19:46 | <webben> | ROBOd, ah ... I'd probably agree with him there. |
| 19:47 | <webben> | ROBOd, I think such systems would ultimately be better safeguards for content. |
| 19:47 | <ROBOd> | doing what hsivonen suggests is technically excellent, but cannot be expected to be done with small web apps, with small web sites, by beginners, or even by experts in small stuff |
| 19:47 | <webben> | ROBOd, Oh I think it can. But as with absolutely everything in this industry ... nobody's built the requisite tools |
| 19:48 | <ROBOd> | webben: i agree, they'd be ultimately better ... but doesn't that add lot of work? currently |
| 19:48 | <ROBOd> | specialised tools, libraries ... can make things much easier, but they are not yet available |
| 19:48 | <webben> | ROBOd, Yes. I don't mean to imply that I expect every webdev to invent this wheel by themselves. |
| 19:49 | <ROBOd> | and those who don't ... are not bozos :) |
| 19:49 | <webben> | (not least because I'd be guilty of patent hypocrisy) |
| 19:49 | <ROBOd> | some of them *are* bozos, but not all |
| 19:49 | <webben> | I just think that's what we need to be working towards collectively. |
| 19:49 | <ROBOd> | yes |
| 19:50 | <webben> | After all we already have tools and libraries that abstract away other (arguably more complex) spheres and make them appear simple |
| 19:50 | <ROBOd> | agreed |
| 19:51 | <webben> | The tragedy is the current set of tools borrowed the UI of word processors (which maps poorly to the web) but not their rigid approach to the document format. |
| 20:04 | <Lachy> | I can't belive what sam has just written here. :-( http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble |
| 20:17 | <Hixie> | ok. change of policy. while i'm still going to reply to all the feedback sent to whatwg⊙wo, when people are just replying to other people and not making any actual suggestions, i'm not even going to pretend to intend to reply to them. |
| 20:17 | <webben> | argh "if documents bodies which were simultaneously both valid HTML5 and valid XHTML5" |
| 20:17 | <Lachy> | I thought you had that policy already |
| 20:18 | <Hixie> | yeah i guess i did |
| 20:24 | <Lachy> | Hixie, which browsers have trouble with a slash immediately following an empty attribute? |
| 20:24 | <Lachy> | if any? |
| 20:24 | <Hixie> | Lachy: oops, i was confused |
| 20:25 | <webben> | Is there any chance of getting back numbering attributes for lists? |
| 20:25 | <Hixie> | aren't they already there? |
| 20:26 | <Lachy> | which ones? start="" and value="" or type="a"? |
| 20:26 | <webben> | i was looking at 3.9.1 for ol |
| 20:26 | <webben> | all i see is start |
| 20:26 | <Lachy> | <li value=""> |
| 20:26 | <webben> | i mean an attribute to specify decimal vs alphabetic vs roman whatever |
| 20:26 | <Lachy> | ah, the type attribute |
| 20:26 | <Hixie> | that's in CSS |
| 20:27 | <Lachy> | the only problem with having the number format in CSS is tha it makes it difficult to refer to an item by number. |
| 20:27 | <webben> | Exactly. |
| 20:27 | <webben> | Which breaks e.g. legal documents |
| 20:28 | <webben> | As i mentioned in my post to the list on annotations |
| 20:28 | <Lachy> | e.g. to say "see point 1.a. in the list" |
| 20:28 | <Lachy> | because, without stylesheets, that a. will default to decimal (or other browser config) |
| 20:28 | <webben> | Nothing terribly wrong with having CSS change these things ... but it should definitely be possible to be part of the markup semantics |
| 20:29 | <webben> | (same problem arises with notes) |
| 20:29 | <webben> | or indeed anything else you might want to count |
| 20:30 | <webben> | Lachy, is this "type" attribute in the HTML5 spec at all, or was that what it was called in old HTML? |
| 20:30 | <Lachy> | it was deprecated in HTML4 and it has not been added to HTML5 |
| 20:31 | <webben> | I see. |
| 20:31 | <webben> | that's bad. |
| 20:32 | <Hixie> | eh |
| 20:32 | <Hixie> | there isn't that much need for it |
| 20:32 | <Hixie> | i agree there are edge cases like legal docs where it has arguably good use cases |
| 20:32 | <webben> | I fail to see how legal docs are an edge case. They do exist on most websites. |
| 20:33 | <Hixie> | yeah but nobody reads them |
| 20:33 | <Hixie> | so who cares :-) |
| 20:33 | <webben> | (i was about to admit that nobody reads them ;) |
| 20:33 | <Hixie> | and most legal documents you read don't actually refer to specific sections so much |
| 20:33 | <webben> | Hixie, eh? yes they do |
| 20:33 | <webben> | at least when i read statutes they do. |
| 20:33 | <Hixie> | not most legal docs |
| 20:33 | <Hixie> | statutes do, sure |
| 20:34 | <Hixie> | but those are the edge case |
| 20:34 | <Lachy> | but the way to make a reference in HTML is to use <a href="#section"> |
| 20:34 | <Hixie> | yeah |
| 20:34 | <Hixie> | there needs to be better support for this |
| 20:34 | <Hixie> | but type="" isn't it, imho |
| 20:34 | <webben> | Lachy, yes but such documents have a deadtree serialization |
| 20:34 | <webben> | so do books with numbered sections ... etc etc |
| 20:34 | <Hixie> | css print should for sure support references for that |
| 20:35 | <webben> | But not everything uses CSS. |
| 20:35 | <webben> | so you end with a discrepancy. |
| 20:35 | <Lachy> | has there been any proposals to handle that use case in CSS? |
| 20:35 | <webben> | I don't see how CSS could handle it. |
| 20:35 | <webben> | Given that CSS is not an essential part of documents. |
| 20:36 | <Lachy> | CSS handles the number style, so it should also handle the reference style |
| 20:36 | <webben> | ah I see what you mean |
| 20:36 | <webben> | But it can't magically make all representations the same. |
| 20:37 | <Lachy> | not yet, but a solution might be found one day |
| 20:37 | <webben> | Or we could use something that's already implemented. |
| 20:38 | <webben> | Given the whole point of CSS is separation I don't see how such a solution would work. |
| 20:38 | <webben> | Because any solution would involve breaking that separation. |
| 20:39 | <webben> | Now one might, it's true, want to change how things are numbered universally. But I think that's a job for transformation tools. /Not/ CSS. |
| 20:40 | <webben> | fixing <ul><li>2.i And as specified in 4.1 [...] </li> [...] </ul> is going to be pretty messy |
| 20:40 | <Hixie> | <ul><li>2.i And as specified <a href="#4i">below</a> [...] </li> [...] </ul> |
| 20:40 | <Hixie> | ...with generated content in CSS |
| 20:41 | <webben> | I still think that's the wrong solution :(. |
| 20:47 | <webben> | did anyone happen to have any thoughts on the feasibility of noteset ? |
| 20:47 | <webben> | I hadn't really been thinking in terms of backwards compatibility |
| 20:47 | <Lachy> | what's noteset? |
| 20:48 | <webben> | sorry, this was in my post on annotations |
| 20:48 | <Lachy> | I don't remember it, maybe it was one that I skipped |
| 20:48 | <webben> | it needs more refinement no doubt, i'm just wondering about the technical possibilities |
| 20:48 | Hixie | has been shunting all annotation discussion into a folder to be opened much later :-) |
| 20:49 | <Hixie> | i'm trying to get to feature freeze for HTML5 here :-P |
| 20:49 | <Hixie> | and people keep suggesting new things :-P |
| 20:49 | <webben> | Hixie, are you serious? I wasn't aware you were seeking a feature freeze |
| 20:49 | <webben> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008190.html |
| 20:50 | <webben> | i suppose "Complex annotations" wasn't exactly a subject title likely to pull in the readers |
| 20:50 | <Lachy> | webben, we have to get to feature freeze somewhere, or it'll never get finished |
| 20:50 | <Hixie> | i'm trying to reach feature freeze by december 31st so that the spec can then be cleaned up and completed before the w3c can get their act together |
| 20:50 | <webben> | a fait accompli |
| 20:50 | <Hixie> | so that if they do end up screwing us over, we at least have one stable spec to hang our hats on |
| 20:50 | <webben> | why not just finish WF2 ? |
| 20:51 | <Hixie> | WF2 is part of HTML5 |
| 20:51 | <webben> | rather than HTML5 as a whole |
| 20:51 | <Hixie> | and is basically done already |
| 20:51 | <webben> | oh, I thought the idea was to have WF2 first then WA1 later |
| 20:51 | <Hixie> | it is |
| 20:51 | <Hixie> | WF2 is done :-) |
| 20:51 | <Hixie> | it's already a W3C spec and everything |
| 20:51 | <Lachy> | When will WF2 be merged into the WA1 document? |
| 20:51 | <Hixie> | dunno |
| 20:51 | <Hixie> | depends what happens with wf2 at w3c |
| 20:52 | <Hixie> | probably in january |
| 20:52 | <Lachy> | ok |
| 20:52 | <Hixie> | but maybe on monday :-) |
| 20:52 | <webben> | it's still wd on the w3c site |
| 20:52 | <Lachy> | that's just going to make the whole spec twice as big as it currently is |
| 20:52 | <Hixie> | webben: yeah, it won't go any further for a while, w3c is slow. |
| 20:52 | <Hixie> | Lachy: yeah, tell me about it |
| 20:53 | <hsivonen> | ROBOd: I haven't defined anyone as a bozo. Tim Bray has. I provide advice on avoiding that label. |
| 20:53 | <webben> | heh |
| 20:53 | <Hixie> | hey hsivonen, what's the name of the relax ng syntax that isn't xml? |
| 20:54 | <hsivonen> | Hixie: RELAX NG Compact Syntax (.rnc) |
| 20:54 | <Hixie> | ta |
| 20:55 | <hsivonen> | ROBOd: http://hsivonen.iki.fi/validator/ does not have a server-side DOM. It has a SAX pipeline with XHTML internally and an HTML5 serializer at last opportunity |
| 20:55 | <hsivonen> | ROBOd: my advice says stack or a tree |
| 20:55 | <hsivonen> | ROBOd: and the runtime stack can be the stack |
| 20:58 | <webben> | I keep trying to do these things with XSLT. Maybe that's my problem. |
| 20:58 | <webben> | Maybe I should be trying to learn Sax instead. |
| 20:58 | <Hixie> | oh lordy |
| 20:59 | <Hixie> | to paraphrase someone whose name i forget: some people, when faced with a problem, think they'll use xslt. now they have two problems. |
| 20:59 | <Lachy> | :-D |
| 20:59 | <webben> | Well XSLT is horrible to begin with. What's worse is all the XSLT processors seem to apply the same instructions differently. |
| 21:00 | <Hixie> | (oh yes, that was jwz and regexps) |
| 21:00 | <Lachy> | is your problem with XSLT the fact that its incredibly complex, difficult to learn, difficult to use and just badly designed? |
| 21:00 | <Hixie> | yes |
| 21:00 | <Hixie> | oh sorry, was i supposed to pick just one? |
| 21:00 | <Lachy> | no, all of the above is fine |
| 21:01 | <Hixie> | tantek can criticise xslt much better than i can |
| 21:02 | <webben> | when you're trying to manipulate and output xslt, do folks find sax makes them happy? Or is just another form of hell? |
| 21:02 | <webben> | *xml not xslt |
| 21:03 | <webben> | how similar are the implementations for example |
| 21:03 | <Hixie> | never used sax myself |
| 21:03 | <Hixie> | then again, i've never output xml from anything but a tree |
| 21:03 | <Hixie> | as far as i recall |
| 21:03 | <Lachy> | I'm working with sax at the moment to implement in my CMS. I'm finding it very easy to work with |
| 21:03 | <hsivonen> | webben: some things are extremely easy in SAX and complicated with trees. some things are complicated in SAX and easy in trees |
| 21:04 | <tantek> | xslt has very poor performance characteristics for any realtime (read: human) applications |
| 21:04 | <webben> | What does it have /good/ performance characteristics for? |
| 21:05 | <tantek> | unknown |
| 21:05 | <Lachy> | when you want to transform some XML into another format, what tool do you recommend instead of XSLT? |
| 21:06 | <Hixie> | actually yeah, performance is the reason google stopped using xslt on at least one of our products |
| 21:06 | hsivonen | notes that http://hsivonen.iki.fi/validator/html5/ uses an XSLT engine behind the scenes for some stuff, but if it becomes a performance problem, it can be replaced with a hand-written SAX checker once the spec is stable |
| 21:08 | webben | seems to remember trying to implement a simple XSLT in Ruby and it taking like 4 seconds per request. |
| 21:08 | <webben> | can't remember which Ruby library I was using |
| 21:08 | <Hixie> | can someone think of any non-HTML-related examples of people using the wrong tool for a job? |
| 21:08 | <webben> | presumably one of the pretty but slow ones |
| 21:09 | <webben> | Hixie, do you mean w/in the field of programming or just generally in life? |
| 21:09 | <Hixie> | either |
| 21:09 | <hsivonen> | Hixie: just about any formal language wrangling by a person who has never heard of parser generators |
| 21:10 | <hsivonen> | (yeah, yeah, I have a hand-written parser, but I did analyze using Antlr, SableCC and JavaCC first) |
| 21:10 | webben | spent ages implementing a parser for the Accept header once, proved more complicated than I expected. |
| 21:11 | <webben> | Then I discovered a decent Ruby lexing tool ... but that was of course too poorly documented for a newbie like me to actually use |
| 21:12 | <webben> | somewhere around that point i gave up and went looking for a language with decent unicode support built in |
| 21:13 | <webben> | Wrong tools. I suppose politics furnishes /loads/ of examples. Unfortunately people are unlikely to agree on which ones are the examples. |
| 21:13 | <hsivonen> | Hixie: using Word for graphics |
| 21:13 | <webben> | ah yeah |
| 21:13 | <webben> | good example |
| 21:14 | <webben> | for most stuff ... paper forms in offices |
| 21:14 | <Lachy> | hsivonen, using Word. period. ;-) |
| 21:14 | <webben> | especially the ones where you employ teams of people to copy the paper forms onto broken database systems |
| 21:15 | <webben> | most office work is a case of the wrong tools actually |
| 21:16 | <webben> | because it all involves this doubling up of deadtree/software solutions which manages to rob both of their benefits |
| 21:16 | <Hixie> | hmm |
| 21:16 | <webben> | plus office politics is not exactly a productive force |
| 21:17 | <webben> | Excel for databases |
| 21:17 | <webben> | that's quite a common one |
| 21:17 | <Hixie> | your paper example made me think of people using books as paperweights |
| 21:17 | <Hixie> | which is the ideal example for my e-mail |
| 21:17 | <webben> | cool :) |
| 21:19 | <webben> | People watching sports on teletext. |
| 21:19 | <webben> | s/People/Brits/ s/sports/cricket/ |
| 21:20 | mpt | (n=mpt⊙1dtn) Quit ("This computer has gone to sleep") |
| 21:34 | Lachy | doesn't understand the paper weights analogy in the e-mail |
| 21:35 | <webben> | HTML is not meant to be parsed as XML. Books are not meant to be used as paperweights. |
| 21:36 | <webben> | (main problem with this is that you should never parse XML as HTML, whereas one may use books as paperweights) |
| 21:36 | <webben> | but it's still funny |
| 21:36 | <Lachy> | It's this sentence that I have the most trouble with: |
| 21:36 | <Lachy> | What you are asking is equivalent to asking bookmakers to make their books heavier and less prone to opening in air currents, because then they would be better paperweights. |
| 21:37 | <Lachy> | specifically, the last bit |
| 21:37 | <webben> | Lachy, because if they open then they catch the air and get pulled away |
| 21:37 | <webben> | and hence cease to be effective paperweights |
| 21:39 | <Lachy> | but the first part says "... make their books heavier and less prone to opening..." and the second part says "... then they would need better paperweights" That just doesn't make sense to me |
| 21:39 | <webben> | eh? |
| 21:40 | <webben> | "because then they would be better paperweights" is the imputed reasoning behind asking bookmakers to ... |
| 21:40 | <webben> | where are you getting "need" from? |
| 21:40 | <Lachy> | if the books are heavier, then there is no need for paperwieghts |
| 21:40 | <Lachy> | maybe it's just the way it's been written, I just don't get it. |
| 21:40 | <webben> | Lachy, I think Hixie means books used to hold other papers down. |
| 21:41 | <Lachy> | oh, wait, I get it now! |
| 21:41 | <webben> | Lachy, if the books are heavier then they are worse books |
| 21:41 | <webben> | :) |
| 21:41 | <Lachy> | I've been misreading it all this time |
| 21:43 | Kanashii | (n=Kanashii⊙plbion) Quit (Client Quit) |
| 21:43 | <Lachy> | I misread it as "then they would NEED better paperweights", rather than "... BE better paperweights" |
| 21:44 | <webben> | ah |
| 21:50 | <Lachy> | added a new question about trailing slashes. (second last question) http://blog.whatwg.org/faq/ |
| 22:04 | <hsivonen> | looks like Sam is interested in the parsing side after all |
| 22:06 | <raspberry-lemon> | Lachy: nice |
| 22:06 | <Lachy> | he seems to be interested in making XML usable as tag soup and tag soup usable as XML. It just doesn't make sense to me. |
| 22:08 | <raspberry-lemon> | as happy as i am about the /> syntax being allowed, i see the point about making sure people understand that it's not necessary, useful or even a good idea |
| 22:08 | <gsnedders> | just a quick question: "For a spec to become a REC, it requires two 100% complete and fully interoperable implementations" - does any implementation count, or only one that has a large user base? |
| 22:09 | <hsivonen> | gsnedders: any |
| 22:09 | <gsnedders> | hsivonen: right. thanks. |
| 22:10 | <Lachy> | the proposed charter for the new HTMLWG in the W3C said of at least 10% market share each, I think. I'm not sure how realistic that is, though. |
| 22:10 | <hsivonen> | gsnedders: assuming that it is shipping (not beta) and available to public to acquire a copy of |
| 22:10 | <Lachy> | http://www.w3.org/2006/11/HTML-WG-charter.html |
| 22:10 | <raspberry-lemon> | wow, i don't see that happening at all |
| 22:10 | ROBOd | (n=robod⊙8321) Quit ("good night all") |
| 22:11 | <Lachy> | perhaps, in 15 years time, when this is even close to becoming a rec, IE won't hold such a monopoly and the major browsers will have around 20% to 30% each |
| 22:13 | <hsivonen> | any public data on what opinion Howcome and Brendan have on the HTML WG charter? |
| 22:17 | <webben> | what defines the market |
| 22:17 | <webben> | e.g. maybe IE isn't in the market for XHTML5 |
| 22:21 | <webben> | (just as it isn't in the market for TEI) |
| 22:21 | <raspberry-lemon> | what's TEI? |
| 22:22 | <Lachy> | webben, I think they would be. They're planning to implement XHTML in IE8 and, it's likely that they'll also follow Moz, Opera and Safari implementations |
| 22:22 | <Lachy> | TEI = Text Encoding Initiative |
| 22:22 | <raspberry-lemon> | ah :) |
| 22:22 | <Lachy> | it's an XML format, that's all I know. |
| 22:25 | <webben> | If we don't count /beta/ implementations, how can we count /planned/ implementations? |
| 22:29 | <Hixie> | "Does HTML allow the use of the empty element syntax from XML on void elements?" is not a frequently asked question. :-) |
| 22:29 | <webben> | heh |
| 22:29 | <Hixie> | "Is it <img/> or is it <img> that is right?" might be |
| 22:29 | <webben> | "Should I close empty elements with /> or > ?" |
| 22:30 | <Hixie> | or that, yeah |
| 22:30 | <Lachy> | that's a better way of asking it |
| 22:31 | <Lachy> | updated. |
| 22:32 | <Hixie> | i love how you're filling in the faq from the bottom up :-) |
| 22:33 | <Hixie> | in general you might want to consider how the faq sounds to newbies who have no idea what you're talking about |
| 22:33 | <Lachy> | I know, that's why I want feedback from more people |
| 22:33 | <Hixie> | e.g. "No, absolutely not." sounds a bit pompous to a newbie :-) |
| 22:33 | <Lachy> | ok |
| 22:34 | <Lachy> | I'm trying to answer the first question now, though |
| 22:34 | <Lachy> | What is the WHATWG and why did it form? |
| 22:34 | <Hixie> | hm |
| 22:34 | <Hixie> | tough one |
| 22:35 | <Hixie> | these days it's a community, i guess |
| 22:35 | <raspberry-lemon> | i mentioned whatwg and html in another channel and was met with "oh no not another bunch of w3 wannabes" :/ |
| 22:35 | <raspberry-lemon> | s/html/html5 |
| 22:35 | <Hixie> | and it formed when mozilla, opera, and apple got together after the web apps and compound documents workshop and said "what?!" to the response from the w3c |
| 22:36 | <Hixie> | raspberry-lemon: heh |
| 22:37 | <Hixie> | the w3c having said "XForms and XHTML2 are going to replace HTML4" |
| 22:37 | <Lachy> | newbies aren't going to know what the web apps and compound documents workshop is |
| 22:37 | <Hixie> | it formed "after a W3C Workshop in 2004"? |
| 22:37 | <Hixie> | you can then link that to the page for that workshop |
| 22:37 | <webben> | You could summarise the cause of the split |
| 22:38 | <webben> | -- need for backwards compatibility + namespaces + ?? |
| 22:38 | <Hixie> | if i knew the cause of their madness... |
| 22:38 | <webben> | well from your POV obviously |
| 22:38 | <webben> | or maybe not present it as a split at all |
| 22:38 | <hsivonen> | http://ln.hixie.ch/?start=1086387609&count=1 |
| 22:39 | <webben> | just emphasize that you're creating a spec with a given set of aims |
| 22:39 | <hsivonen> | http://www.w3.org/2004/04/webapps-cdf-ws/minutes-20040601.html |
| 22:39 | <hsivonen> | http://www.w3.org/2004/04/webapps-cdf-ws/minutes-20040602.html |
| 22:39 | <hsivonen> | (from the .bib for my thesis) |
| 22:40 | <webben> | hsivonen, you're writing a thesis about the split? |
| 22:40 | <Hixie> | that was a weird meeting |
| 22:40 | <Hixie> | Sun, Microsoft, Opera, and Mozilla were agreeing |
| 22:40 | <Hixie> | and everyone else was telling us we were on crack |
| 22:40 | <Hixie> | and we were all like "uh hello" |
| 22:40 | <hsivonen> | webben: no. about the conformance checking service. |
| 22:40 | <hsivonen> | webben: but I am expected to explain the context of the work |
| 22:40 | <Hixie> | "it's SUN and MICROSOFT and MOZILLA and OPERA agreeing here. You cannot FIND four companies that are LESS LIKELY to agree with each other" |
| 22:41 | <Hixie> | "this should tell you something" |
| 22:41 | <hsivonen> | webben: that is, what and why this HTML5 thing is |
| 22:43 | <Hixie> | my favourite part of that meeting, though, was when someone said "But we all agreed that HTML was dead back at the Future of HTML meeting in 1998!" |
| 22:43 | <Hixie> | and I replied "well I can't speak to that, I was still in high school in 1998" |
| 22:47 | <Hixie> | well Lachy, i'm afraid that my solution to the "Classes" section was to drop the section for now. |
| 22:48 | <Lachy> | ok |
| 22:48 | <Hixie> | we really just need to drop profile="" |
| 22:48 | <Lachy> | yes, agreed |
| 22:48 | <webben> | Why? |
| 22:48 | <Hixie> | and switch to first-come-first-served class semantics registration on the wiki |
| 22:48 | <Lachy> | because no-one uses it |
| 22:48 | <webben> | dc metadata |
| 22:48 | <webben> | lots of people use dc |
| 22:48 | <Hixie> | most people using dc metadata do not give the profile="" attribute (I checked) |
| 22:48 | <hsivonen> | webben: in theory. not as practiced |
| 22:48 | <Lachy> | no-one uses it for any real purpose |
| 22:48 | <webben> | is dc on the wiki? |
| 22:48 | <webben> | if not, it needs to be |
| 22:48 | <Lachy> | why? |
| 22:49 | <Lachy> | what tools actually do anything useful with such metadata? |
| 22:49 | <Hixie> | classes aren't yet in the wiki :_) |
| 22:49 | <Lachy> | why should authors bother with it? |
| 22:49 | <Hixie> | when they are, i'm sure dc people will register the dc types |
| 22:49 | <hsivonen> | Lachy: shh. inconvenient question. :-) |
| 22:50 | <Hixie> | hah |
| 22:50 | <webben> | Lachy, There are tools for such metadata. There's an extension for Firefox. |
| 22:50 | <webben> | (whether it checks profile or not I have no idea) |
| 22:50 | <Hixie> | heh, the defined-classes section was dropped in rev 404 |
| 22:50 | <webben> | it's the same with microformats |
| 22:50 | <Lachy> | I really don't understand dc. I leared about it back in school and again in uni, but have yet to find anything that it's actually useful for |
| 22:50 | <webben> | Lachy, Are you a librarian? |
| 22:50 | <Lachy> | no |
| 22:50 | <Lachy> | do librarians actually use it? |
| 22:51 | <Hixie> | surprisingly many people actually specify DC data |
| 22:51 | <Hixie> | dunno if anyone makes use of it |
| 22:51 | gsnedders | cuts in� DC meaning Dublin Core? |
| 22:52 | <webben> | gsnedders, yep |
| 22:52 | <webben> | http://dublincore.org/ ... look at the backing from museums and libraries |
| 22:52 | <gsnedders> | it's used in RSS feeds quite a lot, and most consumers make use of it. As in HTML, I don't know any thing that uses it there. |
| 22:53 | <webben> | http://www.zotero.org/ might |
| 22:53 | <hsivonen> | having worked in the Finnish National Archives thinking about metadata and having been assigned to maintain a metadata spec in the military, I am pretty confident that many people who talk about metadata don't understand processing it in software |
| 22:53 | Lachy | *shrugs* |
| 22:53 | <Lachy> | DC is flawed because it's hidden metadata |
| 22:54 | <hsivonen> | Lachy: DC is flawed, because it is too fluffy for software processing in ways that solves important use cases |
| 22:54 | <webben> | yeah ... Zotero supports it http://www.zotero.org/documentation/compatible_standards_and_software |
| 22:54 | <Lachy> | which reminds me, why are we keeping the meta element for anything but setting the charset? |
| 22:54 | <webben> | it's not hidden --- just go to page info in FF |
| 22:54 | <webben> | and anyway that's because user agents seem to be designed without thinking about academic/educational uses much at all |
| 22:55 | <Lachy> | webben, that counts as hidden! |
| 22:56 | Lachy | thinks the meta element should drop the name attribute and only allow a single meta element for setting the charset |
| 22:57 | mpt | (n=mpt⊙1dtn) Quit ("This computer has gone to sleep") |
| 22:57 | <webben> | And then people will add such citation information where? |
| 22:57 | <webben> | in the text? |
| 22:57 | <Lachy> | in the body of the page, where it's visible |
| 22:58 | <webben> | i suppose they can hide it with CSS |
| 22:58 | <Lachy> | why do you want it hidden? |
| 22:58 | <webben> | Lachy, because it's not important unless your searching or citing |
| 22:58 | <webben> | and thinking about it hiding with CSS isn't good enough because of text UAs |
| 22:59 | <webben> | i suppose they could push it down into the "footer" |
| 22:59 | <webben> | i think moving it out of meta will break existing DC tools |
| 22:59 | <Lachy> | but users need to be able to find the information easily. How many average users do you know that would actuallly look at the page info dialog to read the meta values? |
| 22:59 | <Lachy> | tough. |
| 22:59 | <webben> | Lachy, that's a UA problem |
| 22:59 | <webben> | it's not a problem with the specs |
| 22:59 | <webben> | (and it's solved with extensions/addons) |
| 22:59 | <Lachy> | no, it's an authoring problem. visible data is always better than invisible data |
| 23:00 | <raspberry-lemon> | O,o |
| 23:00 | <webben> | Title is visible. |
| 23:00 | <webben> | The feed links have been made visible |
| 23:00 | <Lachy> | yes, that's right. what's your point? |
| 23:00 | <webben> | those are UA decisions |
| 23:01 | <Lachy> | meta has been around for many years and UAs still don't do anything useful with it |
| 23:01 | <Lachy> | there's no incentive for authors to use it properly |
| 23:01 | <webben> | I don't see that page info is that bad a solution ... except you should be able to extract a citation. |
| 23:01 | <webben> | But then that's what Zotero is for. |
| 23:01 | <Lachy> | those that do think <meta name="description" ...> is actually useful for search engines! |
| 23:02 | <Lachy> | never heard of Zotero |
| 23:02 | <Lachy> | citation information should go on the page, probably in the footer or something |
| 23:02 | <webben> | I just linked to it above. I've never used. But that's because I tend not to have to write paper citations atm. |
| 23:03 | <webben> | hmm ... that will make for much bigger footers |
| 23:03 | <webben> | (the citation i tend to use is stuff to bring the print world into the digital rather than the other way round... e.g. citeulike |
| 23:07 | <webben> | how about a <link> for a page of citation xml or something? |
| 23:07 | <Hixie> | right |
| 23:07 | Hixie | moves on |
| 23:08 | <Hixie> | scripting and threading. |
| 23:08 | <Hixie> | my prediction: nobody will have the slightest comment on this section |
| 23:08 | <Lachy> | why not? |
| 23:08 | <Hixie> | (except a few people who will say "scripting should be multithreaded" and have clue what they're asking for) |
| 23:08 | <Hixie> | because this section is topic to understand :-) |
| 23:08 | <Hixie> | er |
| 23:09 | <Hixie> | this topic is hard to understand |
| 23:09 | <Hixie> | even |
| 23:09 | <Lachy> | right. |
| 23:09 | <hsivonen> | (the xml-dev thread turned out not to be an endless rathole) |
| 23:09 | <Hixie> | uri? |
| 23:09 | <raspberry-lemon> | i'm going to say "scripting should *NOT* be multithreaded" because then i won't have to deal with threading -,-;;; |
| 23:09 | <webben> | what section number is this? |
| 23:09 | <hsivonen> | http://lists.xml.org/archives/xml-dev/200611/msg00253.html |
| 23:10 | <Hixie> | webben: 4.2 right now |
| 23:10 | <Hixie> | of course that can change at a moment's notice |
| 23:10 | <Hixie> | hsivonen: o_O |
| 23:10 | <Hixie> | hsivonen: "by 'processing model suitable for the Web' you mean something useful? if so, we can stop now, because i'm not interested in useful things" ??? |
| 23:10 | <Hixie> | wtf |
| 23:11 | <Hixie> | what world do these people live in |
| 23:11 | <webben> | Does 4.2 imply that a select changes as you move an arrow-key down in the select box? |
| 23:12 | <Hixie> | ? |
| 23:12 | <hsivonen> | Hixie: in the ISO/IEC 19757 aka. DSDL world |
| 23:12 | <webben> | "for controls implemented with a non-editable stateful UI (e.g. select elements, checkboxes, or radio buttons as deployed in typical desktop Web browsers), the change event shall be fired when the selection is completed" |
| 23:12 | <webben> | even if the control does not lose focus. |
| 23:12 | <hsivonen> | ISO/IEC 19757 is good, btw |
| 23:13 | <webben> | what completes a selection in a select box? |
| 23:13 | <webben> | also, is there an event that /is/ triggered by scripted changes? |
| 23:14 | <hsivonen> | (of course, the original non-ISO specs are more readable...) |
| 23:14 | <Hixie> | hsivonen: ah. |
| 23:14 | <Hixie> | webben: 4.2 in web apps 1.0? |
| 23:14 | <webben> | yep |
| 23:14 | Hixie | confused |
| 23:14 | <webben> | oh wait |
| 23:14 | <Hixie> | that's just a red box for me at the moment |
| 23:14 | <webben> | no |
| 23:14 | <webben> | sorry |
| 23:14 | webben | the idiot looks at the wrong doc |
| 23:15 | <Hixie> | heh |
| 23:17 | <webben> | for your list of ways of running scripts, the spec presumably doesn't need to discuss user js/greasemonkey does it? |
| 23:17 | <Hixie> | dunno |
| 23:18 | <webben> | e.g. defining how such scripts might interact with chains of events or something |
| 23:18 | webben | doesn't do much scripting |
| 23:18 | <Hixie> | probably not, since that's just a UA-specific concern |
| 23:18 | <Hixie> | not an interoperability concern |
| 23:18 | <webben> | are there plans for multithreading in JS 2.0 ? |
| 23:19 | <Hixie> | dunno |
| 23:20 | <hsivonen> | webben: doubt it |
| 23:20 | <hsivonen> | webben: considering the threading story of Gecko (lack thereof) |
| 23:23 | <webben> | what about freaky stuff like jscript and vbscript... do those have threads? |
| 23:24 | <hsivonen> | webben: my wild guess is that Trident is multithreaded but jscript achieves Web compatibility by locking |
| 23:25 | <hsivonen> | I wonder how Opera is threaded considering that it runs on esoteric and limited platforms |
| 23:25 | <Hixie> | scripting in opera is run per-instruction, so threading is irrelevant for opera |
| 23:26 | <hsivonen> | Hixie: wow. and still it performs better than Gecko on some things |
| 23:26 | <webben> | in 4.2.1 can we at least include a "UAs should not silently correct errors without user configuration" |
| 23:27 | <webben> | (indeed, given IE already doesn't silently correct errors, could that be a must) |
| 23:27 | <hsivonen> | I had thought that Gecko's suckiness in this area was to cater for the old Mac OS, but timeless explained that it is to deal with the suckiness of X11 |
| 23:27 | <webben> | Doesn't Opera have to deal with the suckiness of X11 too? |
| 23:27 | <hsivonen> | webben: not on HP-UX |
| 23:28 | <Hixie> | webben: correct errors? |
| 23:28 | <hsivonen> | webben: only with XFree86, X.org and the Sun stuff |
| 23:28 | <webben> | Hixie, you know the TAG stuff. |
| 23:28 | <Hixie> | webben: ? |
| 23:29 | <webben> | http://www.w3.org/TR/webarch/#no-silent-recovery |
| 23:29 | <Hixie> | i don't understand what you want the spec to say |
| 23:30 | <webben> | oh i guess it does say that really |
| 23:30 | <webben> | what does "The error should be reported to the user." mean |
| 23:30 | <webben> | e.g. is that something the user can turn off? |
| 23:30 | <webben> | send to the status bar etc..? |
| 23:30 | <webben> | or does that mean give the user a big dialog warning every time? |
| 23:31 | <Hixie> | it means exactly what it says |
| 23:31 | <Hixie> | no more no less |
| 23:33 | <webben> | aren't there two r's in occurred? |
| 23:33 | <Hixie> | probably |
| 23:33 | <Hixie> | the spec is full of typos |
| 23:33 | <webben> | or is occured an Americanism? |
| 23:33 | <Hixie> | it's too early to worry about them |
| 23:35 | <webben> | "the first must give the message that the UA is considering reporting" ... in what form? |
| 23:35 | <webben> | an error number? a string? |
| 23:36 | <Hixie> | whatever it is the UA is considering reporting |
| 23:36 | <Lachy> | http://blog.whatwg.org/faq/#whattf |
| 23:37 | <webben> | why is Applications capitalized? |
| 23:38 | <webben> | "intersted" |
| 23:38 | webben | is sorry for being pedantic |
| 23:38 | <Lachy> | cause I copied it from the whatwg.org home page and didn't change it |
| 23:39 | <Lachy> | fixed |
| 23:41 | <webben> | It would be good if "Headings and sections" included an example that showed where people should put fragment identifiers. |
| 23:41 | <Hixie> | i encourage you to send feedback to the list |
| 23:41 | <Hixie> | on irc it will get lost |
| 23:43 | <webben> | (I've have a vested interest in frag id's because i've been writing a firefox extension to try and make it easier to link to them.) |
| 23:44 | <webben> | the chaos of section id's in old-style html doesn't help |
| 23:45 | <Lachy> | webben, what chaos of section ids? |
| 23:46 | <webben> | there are at least three ways of doing it |
| 23:46 | <webben> | (and that's with people who do it sanely) |
| 23:46 | <Hixie> | i don't suppose anything defines how javascript: URIs work |
| 23:47 | <Lachy> | I don't know of anywhere that defines them |
| 23:47 | <webben> | e.g. <div id="foo"><h2> ... <div><h2 id="foo">... and <div><h2><a name="foo" />... |
| 23:48 | <Hixie> | all of those are reasonable IMHO |
| 23:48 | <Hixie> | the first two are probably preferred |
| 23:48 | <Lachy> | <a name> is no longer in HTML5 |
| 23:48 | <webben> | oh and <div><h2><a name="foo">Foobar</a></h2> |
| 23:49 | <Hixie> | wow, i removed name=""? how radical of me. |
| 23:49 | <Lachy> | and you forgot <h2 xml:id="foo"> ;-) |
| 23:49 | <Hixie> | pff |
| 23:50 | <webben> | so i had some sort of xpath or something trying to pick between those things |
| 23:50 | <webben> | and then when it fails to find those running back up the document looking for them in each preceding "section" |
| 23:50 | <webben> | it makes for a pretty inefficient algorithm |
| 23:51 | <webben> | there's probably a good form for when you want the h2 to be a link |
| 23:51 | <webben> | and a good form for when you just want a "hidden" id |
| 23:52 | <webben> | i can't really see a need for more than two ways of doing it though |
| 23:52 | <webben> | but the fact that <section> can be implied makes things interesting |
| 23:54 | <webben> | hmm it would be good to be clear about whether <h1> should be unique |
| 23:54 | <Hixie> | it does not have to be unique |
| 23:54 | <Hixie> | i thought the spec was clear about that |
| 23:55 | <jgraham> | Do I need an actual gmail account to sign up for Google project hosting? My ordinary Google signin doesn't seem to work :( |
| 23:56 | <webben> | ah it is clear from the examples anyway |
| 23:56 | <Hixie> | webben: examples are not normative, so if the prose doesn't say it, the example could be wrong |
| 23:56 | <Hixie> | jgraham: yes, you need a gmail account (though you don't need to use gmail itself) |
| 23:57 | webben | doesn't grok this headers thing yet |
| 23:58 | <jgraham> | Ah. OK. It would be really useful if there was some useful error message to tell you that |
| 23:58 | <Hixie> | it's in the faq, but i will convey your message to the team |
| 23:59 | <webben> | "header elements must have at least one h1, h2, h3, h4, h5, or h6 element as a descendant." ... is that supposed to mean you can jump from header to h3 |
| 23:59 | <webben> | even though you can't have a header as a descendant of a header |