| 06:29 | <hsivonen> | annevk: it would be super-useful to allow diffing using http://google-diff-match-patch.googlecode.com/ in the Tracker |
| 06:31 | hsivonen | tries to figure out which tokenization states Hixie changed in rev 886. hard to see in diff -u |
| 06:35 | <hsivonen> | rev 886 is so cute |
| 08:33 | <Hixie> | hsivonen: the data state |
| 08:36 | <hsivonen> | Hixie: so I figured using google diff patch match |
| 08:37 | <Hixie> | ah |
| 09:05 | <zcorpan_> | what will <b>x<i>y</b>z</i> parse into? is it <b>x</b><i><b>y</b>z</i> or <b>x<i>y</i></b><i>z</i>? |
| 09:21 | <Fuzzy76> | there is no definite answer to that, it will vary between browsers afaik |
| 09:22 | <citoyen> | Fuzzy76: I assume the question is related to what it will parse as following HTML5 |
| 09:22 | <Fuzzy76> | handling of incorrect nesting is also defined? |
| 09:23 | <zcorpan_> | Fuzzy76: yes |
| 09:23 | <Fuzzy76> | I _really_ need to get through that spec some day :-$ |
| 09:23 | <annevk> | ouch, <!-- and --> parsing in <style> blocks |
| 09:25 | <Fuzzy76> | Every time I say something in here I seem to lodge my foot in my mouth :p |
| 09:31 | <annevk> | that can be solved by reading the spec multiple times in multiple directions |
| 09:31 | <Fuzzy76> | heh |
| 09:31 | <Fuzzy76> | I'll take a note of that :) |
| 09:34 | <Fuzzy76> | heh. Opera print preview didn't like the specs... :p |
| 09:35 | <citoyen> | printing is black magic |
| 09:37 | <Fuzzy76> | It just took a while :) |
| 09:37 | <citoyen> | it's a large file |
| 09:37 | <Fuzzy76> | 401 pages |
| 09:38 | <zcorpan_> | Fuzzy76: http://hsivonen.iki.fi/printing-wa10/ |
| 09:44 | <annevk> | It's funny. You ask for comments on the document itself and people start complaining about HTML5 terminology such as XHTML5 |
| 09:47 | <Fuzzy76> | zcorpan_: Thanks for the tip. :) |
| 09:49 | <annevk> | Ah, the <script><!-- <script> --> </script> makes more sense now |
| 09:50 | <zcorpan_> | annevk: you mean <script><!-- </script> --> </script> ? |
| 09:51 | <annevk> | yeah |
| 09:59 | <annevk> | I wasn't aware it had to do with <!-- and --> |
| 10:01 | annevk | thinks it's kind of neat |
| 10:02 | <hsivonen> | annevk: your latest email to public-html probably had a copy-paste error |
| 10:03 | <hsivonen> | should it say ...(obviously) also not in XHTML5. |
| 10:05 | <annevk> | hmm |
| 10:05 | <annevk> | the attributes of elements, that are in HTML4 but not in HTML5, are not in HTML5 |
| 10:05 | <annevk> | is what I'm trying to say although I wonder how useful it is given the amount of confusion |
| 10:06 | <hsivonen> | isn't it an obvious tautology that stuff that isn't in foo isn't in foo? |
| 10:06 | zcorpan_ | would suggest to drop the paragraph |
| 10:06 | <annevk> | ok, dropped it |
| 10:16 | <mpt> | hsivonen, hendry: <http://news.bbc.co.uk/2/hi/technology/3791983.stm>; describes millions of people who use Java embedded in Web pages |
| 10:16 | <MikeSmith> | annevk - What do you think of DanC's proposed introduction for the HTML5vs4 diff doc? |
| 10:17 | <annevk> | I'm working on that right now |
| 10:18 | <annevk> | The last paragraph needs some work I think |
| 10:18 | <annevk> | HTML became an application of SGML starting with HTML2 |
| 10:18 | <annevk> | and I don't think any implementation ever had a fully conforming SGML parser |
| 10:21 | <hsivonen> | mpt: yeah, games are a case that I'd count as not benefiting from HTML embedding (i.e. better as WebStart) |
| 10:22 | <hsivonen> | mpt: I'm not trying to say that applet don't exist. I was just giving hendry my opinion that applets tend to always be a worse solution than WebStart or JavaScript |
| 10:26 | <MikeSmith> | hmm, I see Hixie recently changed part of the intro of the parsing section to read: |
| 10:26 | <MikeSmith> | [[ |
| 10:26 | <MikeSmith> | The resulting confusion — with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation — has wasted decades of productivity. |
| 10:26 | <MikeSmith> | ]] |
| 10:27 | <MikeSmith> | just added the "wasted decades of productivity" part |
| 10:28 | <mpt> | hsivonen, I haven't used Web Start, but from screenshots I'm not sure that the target audience would understand it well |
| 10:29 | <annevk> | MikeSmith, I don't see that here... |
| 10:30 | <annevk> | I see that now though |
| 10:33 | <hsivonen> | mpt: WebStart does suffer from the same usability vs. security problem as MIDP |
| 10:34 | <hsivonen> | mpt: that is, the defaults are too secure and users are asked to authorize stuff they don't understand |
| 10:34 | <mpt> | MIDP? |
| 10:34 | <hsivonen> | mpt: Java on phones |
| 10:34 | <hsivonen> | mpt: the thing you use to run Opera Mini |
| 10:35 | <mpt> | Actually, I don't :-) |
| 10:35 | <mpt> | but thanks for the explanation |
| 10:35 | <hsivonen> | Opera Mini is the only useful use case I have so far |
| 10:35 | <hsivonen> | although I hear that Google Maps Mini is good, too |
| 10:36 | <hsivonen> | (My phone is too old for Google Maps Mini) |
| 10:36 | <hsivonen> | mpt: anyway, every time I start using Opera Mini, I have to clear an authorization menu, which sucks |
| 10:39 | <MikeSmith> | hsivonen - Opera Mini the only useful use case for MIDP? |
| 10:39 | <hsivonen> | judging from Wii and Maemo, having Flash support in a browser is a much higher priority than having Java applet support |
| 10:39 | <hsivonen> | MikeSmith: so far for me, yes |
| 12:05 | <annevk> | hmm, more expensive checks in the data state |
| 12:05 | <annevk> | there has to be a way to optimize that |
| 12:06 | <hsivonen> | annevk: in a couple of encoding test cases the #data marker lacks a newline after it |
| 12:06 | <hsivonen> | annevk: is there a good reason why? |
| 12:06 | <hsivonen> | annevk: in html5lib |
| 12:07 | <annevk> | I'm afraid I didn't make those |
| 12:08 | <annevk> | Ask jgraham |
| 12:08 | <hsivonen> | annevk: ok |
| 12:09 | <hsivonen> | jgraham: in html5lib/testdata/encoding/tests1.dat there are a couple #data markers without a newline before the actual data. is this intentional? should I fix my harness or should you fix the test data? |
| 12:09 | <virtuelv> | today's fun Firefox bug |
| 12:10 | <virtuelv> | when the bookmarks toolbar is too small to content, Firefox continually dispatches a resize event on the document in view |
| 12:14 | <hsivonen> | jgraham: basically, when I am on a marker line, I skip until and including \n |
| 12:14 | <hsivonen> | jgraham: which fails |
| 12:43 | <hsivonen> | now passing encoding test cases in tests1.dat except for the two with a weird #data marker |
| 12:54 | <hsivonen> | argh. the html5lib encoding tests seem to assume a multicharacter delimiter |
| 12:54 | <hsivonen> | \n# |
| 12:57 | <hsivonen> | and there a place where there are two empty lines before #data |
| 12:57 | <hsivonen> | is the test case format documented somewhere? It seems that I've been making simplified assumptions about the format? |
| 12:59 | <zcorpan_> | http://wiki.whatwg.org/wiki/Parser_tests ? |
| 13:03 | <hsivonen> | zcorpan_: thanks but this is about the encoding sniffing test format |
| 13:03 | <zcorpan_> | ok |
| 13:17 | hsivonen | passes tests2.dat |
| 14:12 | <hsivonen> | whoa! 13 JSON impls in Java to choose from |
| 14:18 | <hsivonen> | down to 3 candidates... |
| 14:25 | <annevk> | hsivonen, I suggest e-mailing implementors⊙wo with html5lib issues |
| 14:31 | <hsivonen> | annevk: instead of filing bugs? |
| 14:34 | <annevk> | guess that might work as well |
| 18:23 | <KevinMarks> | who do I need to persuade to not use <dt><dd> in <dialog> ? |
| 19:02 | <zcorpan_> | KevinMarks: why not and what do you propose instead? |
| 19:07 | <KevinMarks> | because it breaks assumed containment within <dl> and overloads the meaning |
| 19:07 | <KevinMarks> | I propose <q> instead of <dd> |
| 19:08 | <KevinMarks> | for <dt> you could use <cite> |
| 19:09 | <KevinMarks> | I can't see how using <dt> that ambiguously can make any sense |
| 19:10 | <KevinMarks> | <cite> and <q> have exactly the desired semantic as far as I can see |
| 19:10 | <zcorpan_> | <q> is a quotation from another source. in a dialog, you're not quoting from another source, it's direct speech |
| 19:11 | <zcorpan_> | also, html4 suggested <dl> for dialogs |
| 19:11 | <zcorpan_> | so if you followed html4's suggestion it is straight forward to migrate to html5 (just change <dl> to <dialog>) |
| 19:13 | <zcorpan_> | finally, <dt><dd> have a good default rendering for dialogs in legacy browsers |
| 19:22 | virtuelv | agrees with zcorpan_ |
| 19:45 | <KevinMarks> | how is a definition closer in meaning to direct speech than a quotation? |
| 19:45 | <KevinMarks> | seriously? |
| 19:45 | <zcorpan> | <dd> is not a definition |
| 19:46 | <zcorpan> | in html4 it was, loosely, but it is defined differently in html5 (see the spec) |
| 19:46 | <KevinMarks> | it was defined as a definition in html3 |
| 19:47 | <zcorpan> | so? |
| 19:47 | <KevinMarks> | and 4 |
| 19:47 | <zcorpan> | yes, i said that above |
| 19:51 | <KevinMarks> | it is the redefinition I am objecting to |
| 19:51 | <KevinMarks> | it messes up semantic parsing assumptions |
| 19:51 | <KevinMarks> | by all means define new elements for speaker and direct speech |
| 19:52 | <KevinMarks> | but don't redefine others and destroy containment rules |
| 19:56 | <KevinMarks> | how is "description" closer in meaning to "direct speech" than "quote" is ? |
| 19:56 | <KevinMarks> | the spec even says "the discourse, or quote, part in a conversation (dialog element)." |
| 19:59 | <KevinMarks> | did you go away? |
| 20:05 | <Hixie> | how does it mess up any parsing assumptions? any parser that was looking for <dt>s or <dd>s without a <dl> is already broken anyway. |
| 20:08 | <zcorpan> | KevinMarks: in practice, <dl>s are used for all sorts of things. if you see a <dd> that is not inside a <dl> then it was probably used for indentation |
| 20:37 | <gsnedders> | "The new content models only apply to the DOM and the XML serialisations, they can't be expressed in the HTML serialisation." — expressed in what way? |
| 20:40 | <Hixie> | in any way |
| 20:40 | <gsnedders> | but what do you mean by that? |
| 20:41 | <KevinMarks> | so you are saying "people use this ambiguously, so lets make the spec more ambiguous" ? |
| 20:42 | <gsnedders> | how can they be expressed in XML but not HTML? |
| 20:42 | <zcorpan> | KevinMarks: rather make the spec reflect the real world more closely |
| 20:42 | <Hixie> | KevinMarks: it's not made ambiguous, it's made much more precise than html4 ever was. |
| 20:42 | <Hixie> | gsnedders: in XML you could do ...<p><ul>...</ul></p>... |
| 20:43 | <Hixie> | gsnedders: in HTML you can't, since <p><ul> is equivalent to <p></p><ul> |
| 20:43 | <gsnedders> | Hixie: ah. |
| 20:43 | <gsnedders> | Hixie: would it be possible to have such an example in the spec? |
| 20:45 | <Hixie> | i thought i had |
| 20:45 | <KevinMarks> | "The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content." is clearer than "The dd element represents the description, definition, or value, part of a term-description group in a description list (dl element), and the discourse, or quote, part in a conversation (dialog element)." |
| 20:45 | <gsnedders> | I can't find any mention of the fact that it isn't possible in HTML now, even. |
| 20:46 | <Hixie> | 8.1.2.5. Restrictions on content models |
| 20:46 | <Hixie> | i could add an example |
| 20:46 | <Hixie> | send mail asking for one? |
| 20:46 | <Hixie> | KevinMarks: i disagree, but ok |
| 20:48 | <KevinMarks> | so <dd> now means quote, as does <q> |
| 20:48 | <Hixie> | no |
| 20:48 | <Hixie> | it doesn't mean quote |
| 20:48 | <gsnedders> | Hixie: hmm. the prose is clearer than I remember it being. |
| 20:48 | <Hixie> | a quote is something someone else said |
| 20:48 | <zcorpan> | "and the discourse, or quote, ..." |
| 20:49 | <Hixie> | in <dialog>, you might not be quoting anyone (e.g. in a screenplay) |
| 20:49 | <Hixie> | it CAN give a quote |
| 20:49 | <Hixie> | e.g. if the <dialog> is used for transcribing an IM conversation |
| 20:50 | <zcorpan> | yeah, ok |
| 20:51 | <KevinMarks> | Content inside a q element must be quoted from another source |
| 20:51 | <KevinMarks> | IM isn't anotehr source? |
| 20:51 | <zcorpan> | gsnedders: where did you quote that text from regarding content models? |
| 20:51 | <gsnedders> | zcorpan: from a snippet I had lying around of things to question :P |
| 20:52 | <gsnedders> | zcorpan: I can't remember the original source |
| 20:52 | <zcorpan> | ok |
| 20:52 | <Hixie> | KevinMarks: your question seems to imply that if you have a quote you _must_ use <q>. |
| 20:52 | <Hixie> | KevinMarks: which is not the case |
| 20:52 | <Hixie> | KevinMarks: i don't really understand what the problem is you are trying to report. |
| 20:53 | <KevinMarks> | I'm saying <q> is a better SHOULD than <dd> |
| 20:53 | <Hixie> | what for, and why? and what problem does this solve? |
| 20:56 | <KevinMarks> | what problem does redefining <dd> solve? |
| 20:57 | <Hixie> | in <dialog>, you mean? |
| 20:57 | <KevinMarks> | what problem does <dialog> solve? |
| 20:58 | <zcorpan> | people don't know what markup to use for dialogs |
| 20:59 | <Hixie> | <dialog> solves the problem that people have come up with dozens of creative and highly verbose ways of transcribing conversations, none of which handled screenplays and scripts, and all of which were an absolute pain to use in practice. By introducing <dialog>, we can shortcircuit the entire problem with a short syntax, which happens to already work in legacy UAs. |
| 20:59 | Hixie | looks at an e-mail from zcorpan asking for guidance on how innerHTML should handle namespaced nodes |
| 21:00 | <zcorpan> | pointer? |
| 21:01 | <Hixie> | 3 oct 96 |
| 21:01 | <Hixie> | er |
| 21:01 | <Hixie> | 2006 |
| 21:01 | <Hixie> | in it you suggest using the local names for these elements and dropping the prefixes |
| 21:02 | <Hixie> | it's not really clear to me that we shouldn't just raise an exception |
| 21:02 | <Hixie> | i mean, it's not like it's going to round-trip |
| 21:02 | <Hixie> | whatever we do |
| 21:02 | <zcorpan> | a lot of things don't round-trip innerHTML |
| 21:04 | <Hixie> | true |
| 21:04 | <KevinMarks> | so why is <dialog><cite><q> no good? |
| 21:05 | <Hixie> | because you're not citing or quoting anyone in many cases |
| 21:05 | <Hixie> | e.g. screenplays |
| 21:05 | <Hixie> | also, it doesn't really have a good backcompat story |
| 21:05 | <Hixie> | you'd end up with everything in one long line |
| 21:05 | <KevinMarks> | er, you're not defining anyone |
| 21:05 | <Hixie> | ? |
| 21:05 | <Hixie> | what do you mean? |
| 21:06 | <KevinMarks> | you are expanding the meaning of definiiton and term to include speaker and speech |
| 21:06 | <KevinMarks> | but you won't expand the meaning of cite to speaker and quote to speech |
| 21:07 | <Hixie> | we're not expanding the meaning of <dt> and <dd>. <dt> and <dd> when not in a <dl> mean absolutely nothing in HTML4. |
| 21:07 | <Hixie> | the <dt> and <dd> elements in <dialog> elements are entirely new, they just happen to have the same spelling as elements that are used in <dl> elements. |
| 21:07 | <KevinMarks> | so spell them <cite> and <q> |
| 21:08 | <Hixie> | <cite> and <q> have defined meanings everywhere, so we _would_ be redefining them |
| 21:08 | <Hixie> | we would also be doing them a disfavour, by removing the only thing they mean from them in certain cases |
| 21:08 | <Hixie> | and, probable most importantly, you would lose the backwards compatible renderingness |
| 21:09 | <Hixie> | you never answered the three questions i asked earlier: what for, and why? and what problem does this solve? |
| 21:10 | <Hixie> | zcorpan: do you remember what you reasoning was for dropping the prefixes? |
| 21:12 | <KevinMarks> | <dialog><cite>Kevin Marks</cite> <q>agreement</q></dialog> |
| 21:12 | <KevinMarks> | <dialog><dt>Kevin Marks<dd>dissension</dialog> |
| 21:12 | <KevinMarks> | legacy rendition looks OK for the former |
| 21:13 | <Hixie> | <dialog><cite>Kevin Marks</cite> <q>agreement</q> <cite>Ian Hickson</cite> <q>look again</q></dialog> |
| 21:15 | <zcorpan> | Hixie: at least two browsers do it |
| 21:16 | <KevinMarks> | <dialog><li><cite>Kevin Marks</cite> <q>agreement</q> <li><cite>Ian Hickson</cite> <q>look again</q></dialog> |
| 21:16 | <Hixie> | and now we're back to having the creative and highly verbose ways i mentioned earlier |
| 21:17 | <zcorpan> | Hixie: although i see now that safari does what ie does, which neutralises that point |
| 21:18 | <zcorpan> | Hixie: or actually tips it over to me thinking that keeping the prefixes is better (since it's harder to change ie) :) |
| 21:19 | <Hixie> | well this is all highly academic really |
| 21:19 | <Hixie> | but yeah |
| 21:19 | <Hixie> | so you're ok with leaving the same as is? |
| 21:19 | <zcorpan> | leaving what? |
| 21:19 | <Hixie> | the definition of innerHTML |
| 21:20 | <zcorpan> | right now it says what safari/ie do, right? |
| 21:21 | <Hixie> | i believe so |
| 21:23 | <Hixie> | afk for 20 minutes or so |
| 21:23 | <zcorpan> | ok. then yes, i'm ok with leaving it as is |
| 21:38 | <zcorpan> | Hixie: however, none of ie, firefox, opera or safari change the case of the characters when a node is in a different namespace. |
| 21:40 | <zcorpan> | the spec doesn't say to change the case, but it says "(which is all lowercase)" |
| 21:47 | <Hixie> | back |
| 21:47 | <Hixie> | zcorpan: ok, i'll fix that |
| 21:51 | <zcorpan> | hmm, testing "br" elements with contents, in different namespaces, has interesting results |
| 21:58 | <Hixie> | oh? |
| 21:58 | <zcorpan> | will upload tests |
| 22:02 | <zcorpan> | http://simon.html5.org/test/html/dom/the-document/dynamic/in-html/ -- 001 and 002 |
| 22:04 | <Hixie> | wtf is firefox doing |
| 22:05 | <zcorpan> | it is printing the contents of the element first as child of the br, then omitting the end tag, then printing it again as sibling |
| 22:05 | <zcorpan> | for 002 |
| 22:05 | <zcorpan> | safari and opera do the same but don't omit the end tag |
| 22:06 | <Hixie> | but... why? |
| 22:06 | <zcorpan> | no idea |
| 22:06 | <zcorpan> | :) |
| 22:07 | <Hixie> | i guess it's one of those things where the topic comes into play |
| 22:07 | <zcorpan> | perhaps they don't want to drop anything from the dom, and don't print out the contents of empty HTML elements, but instead print out them as siblings |
| 22:08 | <zcorpan> | then apply the same logic to non-HTML elements which results in the same being printed twice |
| 22:08 | <zcorpan> | ie seems to refuse to put contents in br elements |
| 22:08 | <Hixie> | well, the spec just has the contents be omitted |
| 22:08 | <Hixie> | which i think makes more sense anyway |
| 22:09 | <zcorpan> | yeah |
| 22:10 | <zcorpan> | it's not like anyone is using elements with the tag name "br" in another namespace, with contents, and then uses innerHTML |
| 22:10 | <Hixie> | indeed |
| 22:42 | <Hixie> | zcorpan: k, fixed that |
| 23:05 | <jgraham> | hsivonen: The encoding tests thing is a bug which I spotted the other day and is fixed in my local tree |
| 23:05 | jgraham | has a generic parser for tests in that format written which enforces a very simple format |