| 07:29 | <hsivonen> | Hixie: the foreign flag is a two-state separate variable that the tree builder checks for each start tag token before checking the instertion mode aka. 'secondary' insertion mode |
| 07:37 | <Hixie> | hsivonen: that seems like just an extra "if" statement per token |
| 07:37 | <Hixie> | hsivonen: what's the benefit? |
| 07:38 | <hsivonen> | Hixie: the benefit depends on how insertion modes have been implemented |
| 07:39 | <hsivonen> | Hixie: it seems to me that this eliminates a second method / function pointer-based method call per foreign start tag token |
| 07:41 | <hsivonen> | Hixie: I suppose on could eliminate the extra if by rolling the foreign behavior into the main mode switch and by changing the value of the variable to switch on and re-switching when falling back onto the secondary mode |
| 07:42 | <Hixie> | well i don't have an opinion on how you should implement it |
| 07:43 | <Hixie> | but i don't see why a separate switch is better for the way the spec describes it |
| 07:43 | <hsivonen> | was jgraham's infinite loop his bug or a spec bug? |
| 07:44 | <Hixie> | his bug |
| 07:44 | <Hixie> | (and unrelated to the insertion mode) |
| 07:46 | <hsivonen> | ok |
| 08:30 | <hsivonen> | which WG should spec the behavior of XPath being matched against a DOM that is an 'HTML document' for the purposes of the flag defined in HTML 5? |
| 08:30 | <Hixie> | my solution would be "don't use XPath" |
| 08:30 | <hsivonen> | which WG should spec the behavior of the XSLT 'html' output mode in the case of in-browser DOM-to-DOM transform |
| 08:30 | <Hixie> | why is "use the infoset as defined for xml" not satisfactory? |
| 08:30 | <hsivonen> | Hixie: we still need a spec |
| 08:31 | <hsivonen> | Hixie: no |
| 08:31 | <Hixie> | "why" not "is" :-) |
| 08:32 | <hsivonen> | Hixie: for compatibility with existing content, when an XPath expression is used via document.evaluate, a name expression where the namespace is no namespace and local name is /local/, |
| 08:32 | <Hixie> | sounds like xpath would have to define this, if it needs changes to xpath semantics |
| 08:32 | <hsivonen> | must evaluate to true when compared against a DOM element node name whose namespace is http://www.w3.org/1999/xhtml and local name is /local/ |
| 08:33 | <hsivonen> | Hixie: it would be nice to have an informative note about this in HTML 5 |
| 08:34 | <Hixie> | tell me what it should say in a bug |
| 08:34 | <hsivonen> | Hixie: I'll file bugs on XSLT, XPath and HTML 5. |
| 08:34 | <Hixie> | i know only enough about xpath and xslt to know to avoid them |
| 08:34 | <hsivonen> | Hixie: well, that doesn't help me when just following HTML 5 would break mochitests and existing content |
| 08:35 | <Hixie> | just remove the relevant features :-) |
| 08:38 | <hsivonen> | ooh. there's an XSLT 2.1 in the works |
| 08:38 | hsivonen | goes looking for public WDs |
| 08:39 | <hsivonen> | hrm. I can't find a public WD for XSLT 2.1. |
| 08:45 | MikeSmith | looks for XSLT 2.1 also |
| 08:49 | <hsivonen> | where does the XSLT 2.0 spec even define the serialization algorithms? |
| 08:51 | <MikeSmith> | hsivonen: seems that XSLT 2.1 draft is member-only at this point |
| 08:51 | <MikeSmith> | as is pretty much all their draft content |
| 08:52 | <hsivonen> | MikeSmith: thanks. I'll file bugs against the released specs, then. |
| 08:52 | <MikeSmith> | hsivonen: I find http://www.w3.org/TR/xslt-xquery-serialization/ |
| 08:53 | <hsivonen> | If the WG wants to make it know to the general public whether their drafts have the same bugs, they can change the bugzilla fields |
| 08:53 | <hsivonen> | s/know/known/ |
| 08:53 | <MikeSmith> | yeah |
| 08:53 | <hsivonen> | thanks. I didn't realize the serialization spec was separate. |
| 08:54 | <hsivonen> | I was performing random-access reads to XSLT 2.0 and missed normative references if there were any |
| 09:06 | <zcorpan> | hsivonen: maybe you should treat new html5 elements when validating html4 the same as legacy elements when validating as html5 |
| 09:07 | <zcorpan> | hsivonen: i.e. whine about <article> being a new element but don't skip the subtree |
| 09:07 | <jgraham> | Hixie: Actually I need to check that the infinite loop isn't a spec bug because I think I have an if statement left that was supposed to prevent it but, without looking at the code, it seems like it should be unnecessary now |
| 09:07 | <hsivonen> | zcorpan: good idea! |
| 09:07 | <Hixie> | jgraham: is that the same bug you mailed me about? |
| 09:08 | jgraham | thinks some more and realises he's not sure it is unnecessary |
| 09:08 | <jgraham> | Hixie: No |
| 09:08 | <Hixie> | ah ok |
| 09:08 | <Hixie> | so what is the if statement in question? |
| 09:09 | <jgraham> | Hixie: It was about getting a <svg> or <math> element processed as if In Body when In Foreign Content |
| 09:09 | <jgraham> | Which I think sets the secondard insertion mode to In Foreign Content |
| 09:09 | <Hixie> | is there a sample markup snippet demonstrating what you mean? |
| 09:10 | <jgraham> | Hixie: Probably something like <svg><foreignObject><math> |
| 09:10 | <jgraham> | iirc |
| 09:10 | <jgraham> | (maybe you need something else) |
| 09:10 | jgraham | goes to look at the code |
| 09:10 | zcorpan | filed http://bugzilla.validator.nu/show_bug.cgi?id=472 |
| 09:11 | <hsivonen> | thanks! |
| 09:11 | <Hixie> | jgraham: i don't see why that would be a problem |
| 09:13 | <jgraham> | Hixie: The problem I was having, which may or may not have just been a bug, was that both the insertion mode and the secondary insertion mode were In Foreign Content, so hen you hit something that tried to switch the insertion mode to the secondary insertion mode and reprocess the token an infinite loop occurred |
| 09:14 | jgraham | realises he doesn't have the right tree on this computer, gives up |
| 09:15 | <Hixie> | oh yeah |
| 09:15 | <MikeSmith> | hsivonen: about bug 472, the obsolete-element checking for HTML5 is just in the Assertions.java code, right? |
| 09:15 | <hsivonen> | MikeSmith: yes. and legacy.rnc makes them non-errors on the RNG layer |
| 09:15 | <Hixie> | jgraham: i guess we shouldn't change the insertion mode if it's already in foreign, for "math" and "svg" start tag tokens |
| 09:16 | <jgraham> | Hixie: I think that was my if statement :) |
| 09:18 | <Hixie> | jgraham: fixed |
| 09:18 | <MikeSmith> | hsivonen: so implementing a similar mechanism for warning about HTML5 elements in HTML4 checking would require adding a corresponding legacy.rnc with the HTML5 elements, and adding an Assertions.java for HTML4 checking? |
| 09:19 | <hsivonen> | MikeSmith: yes. although now the HTML 4-related assertions are in real .sch |
| 09:19 | <MikeSmith> | OK |
| 09:19 | <hsivonen> | MikeSmith: only because I haven't gotten around to reimplementing that .sch in Java |
| 09:20 | <MikeSmith> | hsivonen: I see. well, if you want, I can take a shot at implementing zcorpan's suggestion and send you a patch to review |
| 09:22 | <jgraham> | Hixie: Thanks |
| 09:27 | <hsivonen> | MikeSmith: that would be nice |
| 09:29 | <MikeSmith> | hsivonen: OK. so this is the schema code in validator/schema/xhtml10/ , right? |
| 09:30 | <hsivonen> | MikeSmith: yes |
| 09:30 | <MikeSmith> | OK |
| 09:30 | <hsivonen> | I've now filed 4 bugs: one on XSLT and XPath each and two on HTML 5 about making notes pointing out the same things. |
| 09:32 | <MikeSmith> | zcorpan: btw, about http://bugzilla.validator.nu/show_bug.cgi?id=467 |
| 09:32 | <zcorpan> | MikeSmith: yes? |
| 09:35 | <MikeSmith> | zcorpan: do you have tests that are not already included in the automated set of tests that validator.nu runs when it builds the "test" target? |
| 09:36 | <MikeSmith> | or is it that the tests need to be incorporated in the JSON mechanism that's there? |
| 09:36 | <zcorpan> | MikeSmith: i don't know which tests are run |
| 09:36 | <MikeSmith> | OK |
| 09:36 | <hsivonen> | MikeSmith: the JSON db is not included in the 'test' run yet |
| 09:36 | <MikeSmith> | ah |
| 09:36 | <hsivonen> | MikeSmith: 'test' runs fantasai's tests |
| 09:36 | <zcorpan> | MikeSmith: i'm not aware of any validator-specific tests i have around other than those at http://simon.html5.org/test/validator/ |
| 09:36 | <MikeSmith> | hsivonen: I see |
| 09:38 | <Hixie> | sicking: document.write() when not in a parser-triggered <script> always implied a document.open() |
| 09:38 | <hsivonen> | (also, when I was developing Web Forms 2.0 validation, 'test' ran a modified version of annevk's Web Forms 2.0 suite, but I can't distribute those files.) |
| 09:38 | <Hixie> | sicking: there is never a race condition that might insert data in a random place in the input stream |
| 09:38 | <Hixie> | sicking: (this matches implementations, and is, i thought, clear in the spec) |
| 09:39 | <MikeSmith> | zcorpan: I see now. I was thinking you had more there, under the content-model subdir |
| 09:39 | <hsivonen> | Hixie: does it match Gecko/WebKit or only IE/Opera? |
| 09:39 | <Hixie> | everyone as far as i know |
| 09:39 | <hsivonen> | Hixie: ok. my recollection is different, but I agree with your point. |
| 09:39 | <Hixie> | there are occasional cases where you can trick some browsers into inserting text in arbitrary places in the input stream, but those seem to be rare bugs |
| 09:41 | <MikeSmith> | hsivonen, zcorpan: anyway, I see now that the purpose of the json thing is to allow testing of remote documents, right? |
| 09:41 | <Hixie> | bed time |
| 09:41 | <Hixie> | nn |
| 09:42 | <zcorpan> | MikeSmith: yep |
| 09:43 | <MikeSmith> | zcorpan: OK. and it requires that v.nu report only a single error message? |
| 09:43 | <hsivonen> | MikeSmith: no, the harness only compares the first message from remote against the first message from db |
| 09:43 | <MikeSmith> | OK |
| 09:44 | <hsivonen> | MikeSmith: http://wiki.whatwg.org/wiki/Validator.nu_Full-Stack_Tests |
| 09:44 | <MikeSmith> | thanks |
| 09:46 | <zcorpan> | MikeSmith: after having fixed a bug, you can do python validator-tester.py adduri url-of-test |
| 09:47 | <MikeSmith> | oh, cool |
| 10:10 | <MikeSmith> | hsivonen: minor problem with this test: |
| 10:11 | <MikeSmith> | http://hsivonen.iki.fi/test/moz/unescaped-ampersand.html |
| 10:13 | <MikeSmith> | failing because db say to expect the error to start at column 7, but v.nu reports it at column 4 |
| 10:13 | <MikeSmith> | should I go ahead and update it before adding other tests? |
| 10:18 | <MikeSmith> | hsivonen: hmm, message output for that case no longer matches either |
| 10:18 | <MikeSmith> | it was: |
| 10:18 | <MikeSmith> | Text after \u201c&\u201d did not match an entity name. Probable cause: \u201c&\u201d should have been escaped as \u201c&\u201d. |
| 10:19 | <MikeSmith> | but v.nu now says: |
| 10:19 | <MikeSmith> | u201c&\u201d did not start a character reference. (\u201c&\u201d probably should have been escaped as \u201c&\u201d. |
| 10:21 | <MikeSmith> | hsivonen: current result seems correct, so should I just update the db.json to that? |
| 10:22 | <hsivonen> | MikeSmith: please do |
| 10:22 | <hsivonen> | MikeSmith: the test harness doesn't care about the text of the error message |
| 10:36 | <MikeSmith> | hsivonen: OK |
| 10:38 | <MikeSmith> | I'll check that in and other the other of zcorpan tests that aren't in there yet |
| 10:39 | <hsivonen> | Can an XPath expression compiler tell from context if a given name expression will match against element names or against attribute names? |
| 11:12 | <Lachy> | looks like there's still some confusion about elements vs. tags. http://blog.whatwg.org/help-us-review-html5#comment-40489 I wonder what can be done to clarify the spec, even though it's already technically correct as is |
| 11:20 | <beowulf> | Lachy: i think i undertand elements vrs tags but i don't understand those two parts of the spec as quoted in that comment... |
| 11:21 | <Lachy> | beowulf, why is it hard to understand that the root element is still present in the document, even though its tags may be omitted from the serialisation? |
| 11:22 | <beowulf> | because i'm an html author, not a ua author? |
| 11:23 | <beowulf> | but i get it now |
| 11:23 | <Philip`> | Depends on whether you view "the document" as a DOM or as a set of tags, I guess |
| 11:25 | <Lachy> | yeah, that can be a little confusing for authors since the exact meaning of "the document" depends on the context in which its used |
| 11:52 | <hsivonen> | did Web Apps inherit all the old DOM specs for maintenance purposes? |
| 12:06 | <annevk2> | hsivonen, sort of, yes |
| 12:07 | <hsivonen> | annevk2: what's the preferred means of reporting spec change requests? |
| 12:09 | <annevk2> | emailing public-webapps or www-dom |
| 12:09 | <hsivonen> | annevk2: thanks. |
| 12:09 | <hsivonen> | I guess I need to read up on the reuse of the www-dom list |
| 12:10 | <annevk2> | it's used for event stuff but has traditionally been the place for issues with dom core as well |
| 12:10 | <annevk2> | since nothing much is happening with dom core until simon's draft is ready it hasn't been used for that recently I suppose |
| 12:11 | <hsivonen> | annevk2: is anyone managing updates to DOM Level 3 XPath? |
| 12:11 | <annevk2> | not really |
| 12:11 | <hsivonen> | annevk2: should I expect Web Apps to update that spec, or should I push for a delta-spec in the "APIs in HTML Documents" section of HTML5? |
| 12:12 | <annevk2> | there was an idea to standardize on an XSLT API as well but that hasn't happened either |
| 12:12 | <hsivonen> | does existing content pass HTML DOMs into such an API? |
| 12:12 | <annevk2> | DOM3XPath is nothing more than a note so I suspect webapps would be the best place |
| 12:12 | <hsivonen> | ok |
| 12:12 | <annevk2> | I'm not really familiar with the XSLT API |
| 12:13 | <hsivonen> | ok |
| 12:13 | <hsivonen> | thanks |
| 12:13 | <annevk2> | though I believe Gecko/Presto/WebKit have one in common and IE has another |
| 12:13 | <hsivonen> | having it in 3 browsers makes me suspect someone out there is already using it on HTML DOMs |
| 12:14 | <hsivonen> | so the XPath hack needs to apply to XPath in the browser in general--not just to document.evaluate |
| 12:14 | <zcorpan> | didn't google docs or something use xslt in the dom? |
| 12:16 | <zcorpan> | does someone have an opinion about Element.parentElement? |
| 12:16 | <zcorpan> | s/some/any/ |
| 12:16 | <annevk2> | doesn't seem harmful |
| 12:17 | <annevk2> | and we have firstElementChild and such too... |
| 12:17 | <zcorpan> | yeah |
| 12:18 | jgraham | is against it |
| 12:19 | <jgraham> | Unless it becomes part of ElementTraversal |
| 12:19 | <jgraham> | Because it is totally redundant with parentNode |
| 12:19 | <annevk2> | why does it matter what it is part of? |
| 12:19 | <annevk2> | I think ElementTraversel should just be integrated in DOM Core fwiw |
| 12:19 | <jgraham> | annevk2: At the moment it is not part of anything at all, right? |
| 12:20 | <annevk2> | it's part of IE, WebKit and Opera |
| 12:20 | <jgraham> | What I really mean is that if it were in some spec I would accept it as inevitable |
| 12:20 | <jgraham> | annevk2: The fact that Firefox doesn't support it suggests that it is not needed for the web |
| 12:21 | <zcorpan> | nextElementSibling wasn't needed for the web, either |
| 12:21 | <jgraham> | AFAICT the only difference between parentNode and parentElement is that in one case you do while(node != document){} and in the other you do while(node != null){} |
| 12:22 | <jgraham> | nextElementSibling actually has a technical advantage for the common case where you want to iterate over elements but not other node types |
| 12:22 | <jgraham> | Although arguably it is redundant with jQuery |
| 12:22 | <zcorpan> | you can have elements in a DocumentFragment |
| 12:23 | <annevk2> | both array index and linked list also is redundant |
| 12:23 | <jgraham> | annevk2: ? |
| 12:24 | <annevk2> | I'm saying that redundancy is a "feature" when it comes to the DOM |
| 12:24 | <annevk2> | it's all over the place |
| 12:24 | <zcorpan> | let's add more! |
| 12:25 | <jgraham> | So your argument is that the DOM is so unweildy that we may as well add any extra feature because it only adds epsilon extra ugliness/confusion? |
| 12:26 | <zcorpan> | always doing whlie (n = n.parentElement) seems simpler than keeping track of what to check for in different cases |
| 12:27 | <jgraham> | I am toatlly unconvinced that the extra simplicity is worthwhile |
| 12:27 | <annevk2> | jgraham, I don't think parentElement is ugly or confusing |
| 12:27 | <jgraham> | annevk2: Do you think it is ugly or confusing to have two different methods that do almost exactly the same thing? |
| 12:28 | <jgraham> | (I agree that, in isolation, parentElement is not particularly bad) |
| 12:28 | <annevk2> | not necessarily, apparently :) |
| 12:28 | <zcorpan> | parentNode and parentElement have descriptive enough names to not be so confusing |
| 12:28 | <hsivonen> | parentElement makes sense for languages that don't do duck typing |
| 12:29 | <hsivonen> | it would make more sense in the Java DOM than in the JavaScript DOM |
| 12:29 | <jgraham> | hsivonen: Presumably the Java DOM has to support .parentNode anyway |
| 12:30 | <hsivonen> | jgraham: yes, but you need to cast it into Element explicitly to get at stuff that isn't on Node |
| 12:30 | jgraham | wishes we could stop designing APIs that are supposed to be programming-language neutral and just design good APIs for the web |
| 12:30 | <annevk2> | I think we're doing that now |
| 12:30 | <jgraham> | annevk2: Really? |
| 12:31 | <annevk2> | when we design new APIs, yes |
| 12:31 | <jgraham> | annevk2: I guess localStorage is a pretty js-friendly api |
| 12:31 | <annevk2> | see e.g. overloading of postMessage |
| 12:32 | <hsivonen> | does WebKit implement XSLT as DOM-to-DOM like Gecko or as DOM-to-characters-to-DOM like IE? |
| 12:33 | <hsivonen> | Opera is like IE here, right? |
| 12:33 | <hsivonen> | (I wonder why, though. If Gecko can get away with DOM-to-DOM, why not Opera?) |
| 12:33 | <Philip`> | Loads of pages use parentElement |
| 12:34 | <jgraham> | Really? I wonder how Firefox gets away with not supporting it… |
| 12:34 | <hsivonen> | jgraham: yes, Firefox does DOM-to-DOM |
| 12:35 | <hsivonen> | jgraham: no disabling output escaping in the transform or document.write in the result |
| 12:35 | <annevk2> | hsivonen, jgraham meant parentElement |
| 12:35 | <hsivonen> | oh |
| 12:35 | jgraham | was rather confused :) |
| 12:35 | <annevk2> | hsivonen, I'm not sure why we do what we do with respect to XSLT |
| 12:35 | <Philip`> | http://www.runningstrong.com/ - |
| 12:35 | <Philip`> | if (elem.parentNode) ... // IE5, IE6 and Netscape 6 |
| 12:35 | <Philip`> | else if (elem.parentElement && elem.parentElement.setAttribute) ... // IE4. |
| 12:35 | <Philip`> | else // Netscape 4.6x or 4.7x |
| 12:35 | <Philip`> | //alert("Must be Netscape! do nothing"); |
| 12:36 | <Philip`> | (Lots of pages have that code) |
| 12:36 | <Philip`> | http://www.evo-solutions.com/ - firedobj=ns6? firedobj.parentNode : firedobj.parentElement |
| 12:37 | <Philip`> | http://villacapri.8m.com/ - while (EventTag.parentElement&&(EventTag.tagName!="A")){ EventTag=EventTag.parentElement; } |
| 12:39 | <Philip`> | http://www.ozteknik.com/ - if (TempJudge && SrcTecMenuIE ){ if (thisobj.parentElement.className=="SrcTecMenuClass"+thisobj.parentElement.id+"On") ... } |
| 12:39 | <Philip`> | and lots of others |
| 12:40 | <Philip`> | (In that last case, SrcTecMenuIE = (document.all)) |
| 12:40 | <zcorpan> | hsivonen: i think opera does reparse because dom-to-dom broke various htmlness issues that a reparse fixed given our architecture |
| 12:41 | <hsivonen> | zcorpan: ah. DOM-to-DOM is magic in Gecko in its handling of local names |
| 12:42 | <hsivonen> | clearly, there would have been a need for a spec for this stuff, since browser differ radically in their implementation approach |
| 12:42 | <zcorpan> | Philip`: thanks. i guess that's reason enough to add it to web dom core |
| 12:42 | <Philip`> | zcorpan: Depends on whether you want to get the IE browser-sniffing path or the Netscape browser-sniffing path |
| 12:43 | <zcorpan> | Philip`: hmm |
| 12:45 | <annevk2> | the ones that check seem to check for parentNode first |
| 12:46 | <zcorpan> | var ns6=document.getElementById&&!document.all |
| 12:47 | <zcorpan> | rather they seem to check for other things than parentElement in their checks |
| 12:48 | <zcorpan> | so if you're not "netscape" you might get the parentElement code path |
| 12:49 | <annevk2> | why does http://www.whatwg.org/specs/web-apps/current-work/?slow-browser#named-access-on-the-window-object list the named elements twice? |
| 12:49 | <zcorpan> | http://www.ozteknik.com/ just uses it without checking |
| 12:50 | <hsivonen> | looks like we don't have interop here: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/64 |
| 12:51 | <hsivonen> | but here we have interop: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/65 |
| 12:51 | <zcorpan> | hsivonen: i think gecko is alone in disabling document.all in standards mode |
| 12:52 | <hsivonen> | oh. right. good point |
| 12:53 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/67 |
| 12:53 | <hsivonen> | Gecko shows a different class compared to WebKit and Opera |
| 12:55 | <zcorpan> | ie8, opera and webkit all say [object HTMLCollection] |
| 12:57 | <zcorpan> | i guess parentElement should be on Node? |
| 12:57 | <annevk2> | is it on Node now? |
| 12:57 | <gavin_> | that "HTML document.all class" dates back all the way to implementation of "undetectable document.all" support |
| 12:58 | gavin_ | can't find any justification for it |
| 12:58 | <gavin_> | bet we could change it! |
| 12:59 | <zcorpan> | hmm the live dom viewer save link doesn't work in ie8 |
| 12:59 | <zcorpan> | it's on Node in webkit |
| 13:00 | <zcorpan> | HTMLElement in opera |
| 13:00 | <zcorpan> | Element in ie8 |
| 13:01 | <zcorpan> | the ElementTraveral attributes are going to be on Node, right? |
| 13:02 | <annevk2> | maybe |
| 13:03 | <zcorpan> | i seem to remember feedback saying they should be on Node but that would be deferred to 2.0 because of willingness to get the spec to REC quickly |
| 13:08 | jgraham | accidentially reads the alt requirements again, realises, again, that they are works of pure fiction compared to what will actually happen |
| 13:16 | <Philip`> | jgraham: The requirements in the spec? |
| 13:16 | <jgraham> | Philip`: Yes. |
| 13:17 | jgraham | probably shouldn't say anything related to alt at all ever |
| 13:20 | <zcorpan> | http://simon.html5.org/specs/web-dom-core#dom-node-parentelement |
| 13:27 | <Philip`> | jgraham: I've generally given up trying to read the spec to work out what my alt text should be, because it seems to go into so much detail that I can't find any relevant advice |
| 13:29 | <zcorpan> | Philip`: would the spec be easier to understand if it said "Conformance requirements regarding the usage of the alt attribute are given in WCAG 2.0."? |
| 13:29 | <Lachy> | Philip`, is that because it doesn't cover your specific case, or because you can't figure out which cases apply to your images? |
| 13:29 | <Lachy> | zcorpan, no. |
| 13:29 | <Philip`> | zcorpan: No |
| 13:30 | <jgraham> | Philip`: I wasn't even trying to write alt text. A search just landed me there and I thought "if I had a dollar for every instance of a screenshot with a precise description of the screen contents on a real website, I would have exactly zero dollars" |
| 13:30 | <zcorpan> | please say so to pf people |
| 13:30 | <Philip`> | Lachy: I can't figure out whether it does cover my specific case |
| 13:31 | <Lachy> | Philip`, can you point to specific case of yours as an example? |
| 13:33 | <Philip`> | Lachy: There was http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-April/014446.html a while ago |
| 13:34 | <Philip`> | The spec has been updated, so maybe it now deals with those specific cases, but the alt description is eight pages long so I'm not going to bother reading it to check |
| 13:35 | <Philip`> | (I could cope much better with more general advice, like saying that pages should remain understandable if all the images are replaced by their alt text) |
| 13:35 | <zcorpan> | Philip`: you can check the toc to see which cases the spec lists |
| 13:37 | <zcorpan> | Philip`: it also has a section called General guidelines |
| 13:38 | <jgraham> | Yeah there could be a conformance requirement like "Pages must be understandable when images are not avaliable" and the alt attribute sould just say "the attribute provides alternative text for an image which is often required comply with the requirements in section x.y.z" |
| 13:38 | <jgraham> | That would annoy the pf people no end |
| 13:39 | <Philip`> | zcorpan: Having the general guidelines hidden underneath a dozen tedious case descriptions is not a good way to make me discover them :-) |
| 13:40 | <zcorpan> | Philip`: bug hixie to move them up |
| 13:41 | <zcorpan> | hmm http://msdn.microsoft.com/en-us/library/ms536654(VS.85).aspx |
| 13:42 | <Philip`> | Reading the TOC doesn't really help either - if I e.g. want to write a page describing a game that's decorated with some screenshots that link to full-size images when you click on them, the first one I noticed when randomly scanning the TOC was "4.8.2.1.6 A purely decorative image that doesn't add any information", which says to use alt="", which is wrong |
| 13:42 | <Lachy> | Philip`, specifically which case in that email? The first one mentioned about the google logo now seems to be fairly well addressed in the spec |
| 13:43 | <Philip`> | Lachy: I don't know, I haven't bothered checking the latest version of the spec because I don't care enough :-p |
| 13:44 | <Lachy> | Philip`, ok. You're making it difficult to undrestand how to address your problems |
| 13:44 | <Lachy> | *understand |
| 13:45 | <jgraham> | Lachy: It seems pretty clear. Make that section of the spec shorter |
| 13:48 | <Philip`> | Lachy: Adding text to the spec to clarify the existing cases or cover new cases to address my problems would just make my higher-level problem (that I'd like to write acceptable alt text but the spec is too verbose and hard to read) worse |
| 13:50 | <Lachy> | making the spec detailed enough to cover all cases is in direct conflict with the desire to make it more concise |
| 13:51 | <Philip`> | It can cover all cases by being more general, rather than by being more detailed |
| 13:51 | <Lachy> | would it be better to instead make the spec easier to navigate and somehow helping people to more easily identify applicable cases |
| 13:52 | <Philip`> | That suggests that authors will write an <img>, think "ooh, I need some alt text", then open the HTML5 spec, navigate to the applicable case, read the instructions, and then write their alt text |
| 13:52 | <jgraham> | We could write a text-based adventure frontend to the spec |
| 13:52 | <Philip`> | which is horribly inefficient |
| 13:52 | <Lachy> | since I'm going to have to eventually explain this in the authoring guide, it would be good to figure out how to make that more approachable than the spec. |
| 13:52 | <Philip`> | and therefore unlikely to happen |
| 13:52 | <jgraham> | "You are in a maze of twisy reccomendations, all alike" |
| 13:53 | <jgraham> | "It is dark, you are likely to be eaten by a lawyer" |
| 13:53 | <beowulf> | can't you just decide to dump @alt? |
| 13:55 | <Philip`> | It's more realistic if the author writes an <img>, thinks "ooh, I need some alt text", then remembers an approximation of the nice concise description of alt they read in the HTML5 spec six months ago, and then writes their alt text, and nobody points at them and laughs and says "you're a moron, section 4.8.2.1.11.6.9 specifically addresses this image and says you should write this specific text" |
| 13:55 | <zcorpan> | Lachy: copy the general guidelines section, then say "for more detail or suggestions for specific cases, refer to the spec" |
| 14:57 | <annevk2> | hsivonen has awoken the XML gods: http://twitter.com/elharo/statuses/1462873257 |
| 14:59 | <hsivonen> | annevk2: too bad the removal of the Selectors special case introduced an XPath special case |
| 15:00 | <annevk2> | better XPath special case than special cases in the more commonly used features |
| 15:01 | <MikeSmith> | "The only thing they hold sacred are 10-year old browser bugs." |
| 15:01 | <MikeSmith> | beautiful |
| 15:01 | <MikeSmith> | we should start a quotations page |
| 15:01 | <hsivonen> | it's a DOM Level 2 / XHTML 1.0 issue, actually... |
| 15:02 | <hsivonen> | or Namespaces issue... |
| 15:02 | <annevk2> | yeah, it's clear from the accusation that he hasn't really followed what this is about |
| 15:02 | <MikeSmith> | we should do like Elijah, line up the priests of Baal and put them all to a test |
| 15:03 | <hsivonen> | of course, this wouldn't be an issue if XPath had had a namespace wildcard by default like Selectors |
| 15:03 | <hsivonen> | a lot of issues can be traced down to Namespaces sucking in the first place |
| 15:04 | <hsivonen> | or more precisely, the changing naming from a single string into a pair |
| 15:04 | <MikeSmith> | and everybody knew it was f*ucked up from teh beginning |
| 15:04 | <gsnedders> | MikeSmith: :) |
| 15:05 | <annevk2> | which can be traced back to RDF which is why XML has namespaces |
| 15:05 | <hsivonen> | indeed |
| 15:05 | <annevk2> | a Semantic Web seed carefully planted to make the current Web more complicated... |
| 15:09 | <annevk2> | http://twitter.com/distobj/status/1462908234 more rambling without reading |
| 15:13 | <zcorpan> | <title role="html:h1">? |
| 15:14 | <hsivonen> | wouldn't architectural forms be more like <div html="h1">? |
| 15:15 | <MikeSmith> | ah, more gems |
| 15:16 | <MikeSmith> | "the IETF tries to master entropy" |
| 15:20 | <takkaria> | "The correct solution is simple: require namespace well-formedness for HTML 5 documents. Until the spec takes that simple step, ..." |
| 15:22 | <jcranmer> | where is this? |
| 15:22 | <takkaria> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 |
| 15:22 | <Philip`> | "The difference between the IETF and the WHATWG is that the WHATWG respects the laws of thermodynamics" |
| 15:23 | <MikeSmith> | like Christian Democrats asserting that existing social institutions work just fine, but the problem is just that people don't follow the (arbitrary) rules, therefor the solution is to fine ways to compel/force more people to just bend to their will and follow the rules |
| 15:23 | <gsnedders> | http://www.youtube.com/user/ie8videos |
| 15:24 | <MikeSmith> | faith-based specification development |
| 15:25 | <MikeSmith> | maybe they can get some US government funding for their work |
| 15:25 | jcranmer | wants to smack comment 8 |
| 15:27 | <MikeSmith> | the problem with the whatwg is that it's soft on crime |
| 15:28 | <jcranmer> | does she realize she's asking the impossible? |
| 15:28 | <annevk2> | she? |
| 15:30 | <gsnedders> | A female name, like Anne :P |
| 15:30 | <Philip`> | jcranmer: Things that are impossible just take longer |
| 15:31 | <Lachy> | jcranmer, comment 8 where? |
| 15:31 | <jcranmer> | Elliotte -- names that end in -te tend to be feminine |
| 15:31 | <jcranmer> | Lachy: 10:27 < takkaria> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 |
| 15:32 | <gsnedders> | MikeSmith: Also, to make you happy, I've now almost finished dissertation on Nabokov |
| 15:32 | <Philip`> | jcranmer: Like "Pete"? |
| 15:32 | <jcranmer> | I said "tend to be" |
| 15:32 | <jcranmer> | besides, Pete is usually short for Peter |
| 15:32 | <MikeSmith> | gsnedders: you would make me really happy if you told me that you burned it after you finally have it done |
| 15:32 | <Lachy> | jcranmer, Elliotte sounds more like a male name. But that depends how its pronounced |
| 15:33 | <MikeSmith> | gsnedders: that's what all great creative types do |
| 15:33 | <MikeSmith> | Sibelius, etc. |
| 15:35 | <Philip`> | And there's that guy on Youtube who built an image out of matchsticks and then burnt them all |
| 15:37 | Philip` | wonders if Elliotte is an unusually rare name, or if elharo just has a lot more page-rank than all the others |
| 16:05 | <zcorpan> | hsivonen: you should try to get http://v.nu/ |
| 16:08 | <Philip`> | If that's taken, try http://ν.nu |
| 16:08 | <hsivonen> | zcorpan: earlier, when it was up for auction, I decided that it wasn't worth my money (or Mozilla's money) at its price. |
| 16:08 | <hsivonen> | zcorpan: I forgot what the price was. |
| 16:09 | <zcorpan> | ok |
| 16:09 | Philip` | wonders why .nu |
| 16:09 | <hsivonen> | zcorpan: also, I didn't like the idea of paying a squatter |
| 16:09 | <MikeSmith> | hsivonen: I think it was that they auction the single-letter domains, and it starts at 500 euro or so |
| 16:10 | <MikeSmith> | hsivonen: I don't think it's necessarily a squatter |
| 16:10 | <MikeSmith> | or maybe it was in this case |
| 16:10 | <hsivonen> | Philip`: it was the least ugly (the only? I forget) validator.tld domain available |
| 16:11 | <hsivonen> | Philip`: also, you are supposed to pronounce "nu" like English "new"--not like French "nu" :-) |
| 16:11 | <Philip`> | Ah, okay |
| 16:11 | Philip` | pronounces it like English ν :-) |
| 16:11 | <Philip`> | (which is like "new") |
| 16:12 | <zcorpan> | hsivonen: or like swedish "nu" (which means "now") :) |
| 16:12 | gsnedders | pronounces like French "nu" :) |
| 16:12 | <Philip`> | (at least according to the mathsy people who I've heard use that term) |
| 16:13 | <hsivonen> | MikeSmith: I think it was more expensive than 500 EUR the last time |
| 16:13 | <hsivonen> | but like I said, I forgot |
| 16:14 | gsnedders | thinks he should start editing his English dissertation |
| 16:14 | gsnedders | sighs |
| 16:14 | <gsnedders> | When will I finish it!? |
| 16:14 | <gsnedders> | (Likely answer: hours before it has to be sent off.) |
| 16:15 | <hsivonen> | whoa. Hixie is not on IRC. screen died perhaps? |
| 16:17 | <Philip`> | gsnedders: Why waste hours of valuable editing time before it has to be sent off? |
| 16:17 | <hsivonen> | does Chrome support XSLT? |
| 16:18 | <hsivonen> | according to w3schools, yes |
| 16:18 | hsivonen | ducks having used w3schools as a reference |
| 16:18 | <zcorpan> | hsivonen: w3c can't be wrong |
| 16:34 | <gsnedders> | Wikipedia is so much easier than trying to find information from an entire novel |
| 16:43 | <Lachy> | http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html |
| 16:45 | <hsivonen> | perhaps HTML 5 should say that <time> is not safe for historians |
| 16:45 | <hsivonen> | I thought it already did |
| 16:45 | <hsivonen> | so more clearly than now |
| 16:48 | <Lachy> | I thought it did too, but it seems that it isn't clear enough |
| 16:48 | <Lachy> | I don't understand what PPK means by allowing "arbitrary year-naming systems to be specified" |
| 16:52 | <zcorpan> | seems pointless to have a cutoff date at 1870 or 1918 |
| 16:54 | <Philip`> | Seems pointless to have a cutoff date at 1 |
| 16:54 | <zcorpan> | the point with having it at 1 is that it keeps the syntax simple |
| 16:56 | <Lachy> | Philip`, the cut off date was set to 1 because anything else would be competely arbitrary and it made things simple without requiring syntactic changes |
| 16:57 | <annevk3> | times/dates suck |
| 16:58 | <Philip`> | Lachy: Negative infinity would be less arbitrary than 1 |
| 16:59 | <Philip`> | (I guess 0 would be less arbitrary than 1 too) |
| 16:59 | <Lachy> | negative dates would require additional syntax and give teh false impression that time is designed for historical dates |
| 16:59 | <Lachy> | there was no year 0, so we had to pick 1 |
| 17:00 | <Philip`> | Syntax is a pretty trivial issue |
| 17:01 | <Lachy> | sure, the changes to the algorithm and implementation needed to support dates beginning with a '-' is trivial. But completely unnecessary |
| 17:01 | <Philip`> | There's a year 0 in the ISO 8601 proleptic Gregorian calendar |
| 17:01 | <Philip`> | and it's just as meaningful as year 1 |
| 17:01 | <Lachy> | yes, but that's confusing because year 0 in 8601 is 1BCE |
| 17:02 | Philip` | doesn't find that confusing :-) |
| 17:02 | <Lachy> | Philip`, ask some random people whether -0004-01-01 is 3BCE or 4BCE. |
| 17:03 | <Lachy> | or 5BCE |
| 17:03 | <Philip`> | Random people probably would never recognise it as a date |
| 17:03 | <Lachy> | well, HTML authors who are familiar with the ISO-8601 syntax |
| 17:04 | <Lachy> | i.e. people who use hCalendar |
| 17:13 | <Philip`> | Lachy: Ask the same people whether 2 September 1666 is 1666-09-02 or 1666-09-12 and they'll probably get it wrong too, but we're not trying to protect them from that |
| 17:16 | <Lachy> | Philip`, I'm sure they would get that wrong too. But choosing to explicitly add support for negative years when we know it's problematic is different from supporting pre 16th century dates simply as a result of the syntax |
| 17:16 | <Lachy> | actually, 17th century, but whatever. |
| 17:18 | <krijnh> | Are people here okay with me moving the logs over to my new website, http://www.krijn-engineering.nl/ ? |
| 17:20 | <Lachy> | krijnh, if you set up a redirect, yes |
| 17:21 | <Philip`> | krijnh: I like your use of a 404 in a <bgsound> |
| 17:21 | <krijnh> | Philip`: what? Ow, that's a bug then :/ Damnit |
| 17:22 | <Philip`> | krijnh: You need to be more careful when you're uploading your web site from Word |
| 17:23 | <annevk3> | you'd think krijnh would know a bit about HTML after logging this channel for two years |
| 17:23 | <Lachy> | krijnh, wtf? Why have you published a page created with Microsoft Office? |
| 17:24 | <krijnh> | How do you know it's made with Office? |
| 17:24 | Lachy | collects krijnh's whatwg cabal membership card. |
| 17:24 | <krijnh> | I thought I stripped out that code :/ |
| 17:24 | <Lachy> | look at the source. |
| 17:24 | <annevk3> | punk'd |
| 17:24 | <annevk3> | :D |
| 17:25 | <Philip`> | krijnh: Surely you should write that page with SVG rather than VML |
| 17:26 | <krijnh> | *sigh* |
| 17:26 | <krijnh> | You're way too elitist you! |
| 17:26 | <krijnh> | Not everybody can handcode HTML :( |
| 17:26 | <Philip`> | You don't need to handcode it - just use Inkscape |
| 17:27 | <Philip`> | and then use Amaya to merge it with the HTML |
| 17:27 | <krijnh> | In fact I did, and after that I copied it to Word, cause the margins were easier to manage in Word |
| 17:27 | <annevk3> | but Word also kills babies |
| 17:27 | <krijnh> | The rounded corners were pretty hard to create in Word, so that's why I used Inkscape |
| 17:27 | <krijnh> | But it's not finished yet |
| 17:28 | <krijnh> | I think the design should be centered |
| 17:29 | <Philip`> | Needs more clipart |
| 17:29 | <hsivonen> | is the use of OOo allowed? |
| 17:30 | <krijnh> | I'll tell it to my webdesinger |
| 17:31 | <hsivonen> | I blame all the uppercase tags on my site on OOo. |
| 17:33 | <Philip`> | You should use Tidy |
| 17:34 | <hsivonen> | why? |
| 17:34 | <Philip`> | To make things tidy |
| 17:34 | <Philip`> | like lowercasing tags |
| 17:35 | <hsivonen> | the ROI is unclear to me |
| 17:36 | <annevk3> | ISO 8601 is not Y100K proof |
| 17:37 | <Philip`> | Human civilisation is not Y100K proof |
| 17:37 | <tantek> | Lachy, Philip' - supporting day-precise negative years or even years 18th century and earlier is asking for a heap of trouble/complexity |
| 17:37 | <tantek> | no matter the format |
| 17:37 | <annevk3> | Philip`, that's unclear |
| 17:38 | <Philip`> | hsivonen: If you "blame" something for uppercase tags, presumably you dislike uppercase tags, and hence there would be some aesthetic value in lowercasing them |
| 17:38 | <Philip`> | annevk3: History is probably a good indicator, in the absence of any other evidence |
| 17:38 | <annevk3> | Philip`, it might be that the calendar format we have is not Y100K proof though |
| 17:39 | <Philip`> | Not even the Romans lasted a hundred thousand years |
| 17:39 | <annevk3> | Philip`, Romans are a subset of human civilisation... |
| 17:40 | <gsnedders> | tantek: I don't think anyone apart from those who are saying we must support such things or else time is pointless thinks that isn't the case |
| 17:41 | <tantek> | let them see this chart then, and write the *location*-sensitive code themselves: http://en.wikipedia.org/wiki/Gregorian_calendar#Timeline |
| 17:41 | <Philip`> | tantek: We've already asked for the heap of trouble by trying to support dates at all - if we don't support ancient dates then we have some arbitrary cutoff date instead, which will just cause different kinds of trouble |
| 17:41 | <gsnedders> | Oh yeah, they've brought up the complexity caused by that, and said we should just provide a means to provide dates in other calendars to circumvent that problem |
| 17:42 | <tantek> | Philip' no need to have an "arbitrary" cutoff date, simply use 1926 as the cut-off and cite http://en.wikipedia.org/wiki/Gregorian_calendar#Timeline as the justification |
| 17:42 | <tantek> | and invite counter-proposals with *better* justifications/citations |
| 17:43 | <Philip`> | tantek: Sounds pretty arbitrary to base it on when Turkey switched calendar |
| 17:43 | <tantek> | Philip' - it's simply the last country to switch over in that list |
| 17:43 | <Philip`> | and introduces unnecessary complexity if e.g. a UK-based site wants to mark up people's dates of birth |
| 17:43 | <gsnedders> | tantek: They have given counter-proposals of allowing an attribute to specify the calendar in use for the date format |
| 17:44 | <tantek> | thus from 1926 on, you know that Gregorian dates are consistent worldwide |
| 17:44 | <hsivonen> | Philip`: s/Turkey/Greece/ ? |
| 17:44 | <hsivonen> | oops. |
| 17:44 | hsivonen | read the wrong sentence on wikipedia |
| 17:44 | <tantek> | gsnedders, based on what evidence that people specify alternative calendars? |
| 17:44 | <tantek> | RFC2445 similarly has such a field, but in practice it is always GREGORIAN |
| 17:45 | <hsivonen> | (someone should mention Turkey in the wikipedia prose in addition to the image that doesn't respond to Find on Page) |
| 17:47 | <Philip`> | tantek: If Saudi Arabia decided tomorrow to switch from the Islamic calendar to the Gregorian, should we restrict <time> to use 2009 as the cut-off? |
| 17:48 | <annevk3> | reading http://tools.ietf.org/html/rfc3339#appendix-A I wonder why some people argue we should simply reference ISO 8601; seems like a disaster |
| 17:48 | <tantek> | Philip - I call theoretical. E.g.: if aliens showed up tomorrow with a better datetime format, should we switch to use it? |
| 17:49 | <annevk3> | i think we should form a comittee and compromise between all the various formats |
| 17:50 | <gsnedders> | tantek: Evidence? They're trolls, they don't need evidence. |
| 17:50 | <annevk3> | (that RFC syntax also does not allow Y10K) |
| 17:50 | <tantek> | lacking evidence, trolls can be ignored. |
| 17:52 | <tantek> | annevk3 - in that case, here is my proposed new calendar: http://tr.im/newcal |
| 17:52 | <Philip`> | tantek: So the cut-off date should be defined as the date that the latest country officially switched to the Gregorian calendar according to Wikipedia (ignoring China which is complex) before 2009? |
| 17:53 | <tantek> | Philip', see above, you are free/encouraged to provide "counter-proposals with *better* justifications/citations" |
| 17:53 | <tantek> | (wow PBWiki 2 forced upgrade (really a downgrade) really screwed up some markup) |
| 17:55 | <Philip`> | tantek: I counter-propose setting the cut-off date at 1, which is justified by being useful for a wider range of use cases and by being easier to remember and by not depending on quite so many pieces of irrelevant trivia :-) |
| 17:55 | <annevk3> | of course ECMAScript is even worse as it does not define Date parsing at all :/ |
| 17:57 | <tantek> | Philip - that's a reasonable counterproposal, you may want to add some wording about sticking to ISO8601 and for any dates in locations before they supported the Gregorian calendar, that they MUST use Proleptic Gregorian dates per http://en.wikipedia.org/wiki/Gregorian_calendar#Proleptic_Gregorian_calendar |
| 17:59 | tantek | has begun using ordinal ISO8601 dates with a hyphen http://en.wikipedia.org/wiki/ISO_8601#Ordinal_dates for filing/dating/signing purposes. |
| 18:01 | <gsnedders> | tantek: Why ordinal? |
| 18:01 | Philip` | can only use year/month/day, because he can only remember year and his watch only tells him month/day |
| 18:03 | <tantek> | gsnedders - easier to do day math (how many days between date x and date y), and convert between Gregorian and NewCalendar |
| 19:43 | <Hixie> | hsivonen: having one cake and eating another kinda misses the point of the expression :-P |
| 19:50 | <tantek> | Hixie, clearly the expression must have been underspecified. |
| 19:51 | <hsivonen> | Hixie: do you have an actual solution to the problem (other than "don't implement XPath")? |
| 19:51 | <Hixie> | i don't understand the problem in enough detail to have an educated suggestion |
| 19:52 | <hsivonen> | The problem is this: |
| 19:52 | <hsivonen> | XPath has been exposed to content before the namespace unification |
| 19:52 | <hsivonen> | therefore, existing expressions expect HTML elements to be in no namespace |
| 19:53 | <hsivonen> | and XHTML elements to be in http://www.w3.org/1999/xhtml namespace |
| 19:53 | <annevk3> | arguably XPath for HTML is undefined so we can do whatever we want |
| 19:53 | <hsivonen> | We'd want to change things so that you can write one kind of new expressions for both *and* keep the old expressions out there matching, too |
| 19:54 | <hsivonen> | By default, the syntax people actually use doesn't wildcard the namespace as is the case with Selectors |
| 19:54 | <hsivonen> | instead, the namespace is fixed to be the 'no namespace' |
| 19:54 | <hsivonen> | in the XPath data model, a node can be in only one namespace |
| 19:55 | <hsivonen> | so to support both future expressions that use the http://www.w3.org/1999/xhtml namespace and past expressions that use no namespace, WebKit violates the XPath data model |
| 19:56 | <hsivonen> | I have tentatively implemented the exact same violation in a patch for Gecko |
| 19:56 | <hsivonen> | annevk3: we can do whatever we want only if we are OK with breaking existing expressions |
| 19:56 | <jgraham> | hsivonen: It seems like an entirely reasonable and necessary violation to me |
| 19:57 | <jgraham> | Since I agree that there is a constraint that existing expressions should not be broken |
| 19:57 | <annevk3> | hsivonen, I mean we can "violate" XPath because technically it is not a violation as XPath for text/html is not defined |
| 19:57 | <hsivonen> | arguably, the violation could be adjusted to be a bit more sane if a no-namespace expression no longer matched no-namespace elements |
| 19:57 | <hsivonen> | when now in WebKit, it matches both no-namespace nodes and HTML nodes |
| 19:58 | <hsivonen> | annevk3: It's a violation of XPath if you cannot explain the behavior in terms of the XPath data model |
| 19:58 | <jgraham> | hsivonen: Would there still be a way to match no-nemaspace elements? |
| 19:58 | <hsivonen> | jgraham: no |
| 19:58 | <hsivonen> | jgraham: but one might argue no one should have no-namespace nodes in HTML trees anyway |
| 19:59 | <annevk3> | hsivonen, saying that no namespace and the XHTML namespace are identical for HTML trees is not good enough? |
| 19:59 | <jgraham> | One could argue lots of things :) |
| 20:00 | <hsivonen> | annevk3: one might claim that the mapping to XDM not be bijective and that both no-namespace nodes and XHTML nodes flatten into one in XDM |
| 20:00 | <jgraham> | I think making XPath match either no-namespace or HTML namespace makes a lot of sense. |
| 20:00 | <annevk3> | XPath is indeed an exception btw, the DOM, Selectors, usually default to any namespace |
| 20:00 | <hsivonen> | annevk3: but that's still not enough to explain the WebKit behavior in terms of XDM |
| 20:00 | <gsnedders> | hsivonen: Can it not just be specified in terms of DOM-like interface in HTML 5? |
| 20:00 | <hsivonen> | annevk3: because a node can have only one namespace in XDM but we want both no-namespace and http://www.w3.org/1999/xhtml-namespace expressions to match against the same nodes |
| 20:01 | <gsnedders> | i.e., this should follow DOM Level 3 XPath, but HTML elements should behave as if they are in no namespace |
| 20:01 | <hsivonen> | gsnedders: the interface requires an additonal datum that isn't in XDM: the HTMLness flag on owner doc |
| 20:01 | <annevk3> | "This is a willful violation of the XDM." |
| 20:01 | <hsivonen> | gsnedders: unless you violate XML to XDM mapping in XHTML, too... |
| 20:01 | <gsnedders> | IMO XPath is the wrong place to spec this |
| 20:01 | <annevk3> | hsivonen, we can argue that in our XDM no namespace is the XHTML namespace |
| 20:02 | <annevk3> | hsivonen, that there's no distinction in our XDM |
| 20:02 | <annevk3> | hsivonen, for the purposes of the XDM, anyway |
| 20:02 | <annevk3> | hsivonen, but I'm not that interested in spec-lawyering, lets just deal with the fallout in 5 years rather than now :) |
| 20:03 | <hsivonen> | annevk3: the thing is, in terms of XDM, you only get to flatten things in the tree |
| 20:03 | <hsivonen> | annevk3: you don't get to flatten things in the expressions themselves |
| 20:05 | <jgraham> | hsivonen: annevk3 has a point. It is pretty clear what implementations have do do. We should ship the software then spec the required behaviour |
| 20:05 | <jgraham> | Since it's hard to argue with interoperable running code |
| 20:07 | jgraham | wonders if that is somehoe not playing by the rules |
| 20:07 | <hsivonen> | jgraham: well, as you can see, what I did with code was to do exactly what WebKit does |
| 20:07 | <Hixie> | doing what webkit does seems like the simplest solution |
| 20:07 | <gsnedders> | What does WebKit do, exactly? |
| 20:07 | <gsnedders> | Does it only apply for HTML documents, or for all documents? |
| 20:07 | <hsivonen> | Hixie: the simpler solution is not to unify HTML and XHTML XDMs |
| 20:08 | <hsivonen> | Hixie: so that even future XPath would always have to be different for the two |
| 20:08 | <hsivonen> | Hixie: even if JS and Selectors Just Worked |
| 20:08 | <hsivonen> | it seems like an undesirable outcome not to be able to write unified XPath for HTML and XHTML, though |
| 20:10 | <Hixie> | hsivonen: s/simplest/best/ then |
| 20:16 | tantek | is a bit amazed. |
| 20:17 | <tantek> | which spec does Webkit violate? (URL?) |
| 20:17 | <tantek> | and is there a description for how it violates it, and *why*? (URL aside from #whatwg IRC logs) |
| 20:18 | <Hixie> | two bonus points to anyone who can guess the [[Class]] name of the element created by document.createElement('keygen') |
| 20:20 | <hsivonen> | tantek: XPath. and http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 |
| 20:20 | <hsivonen> | (sorry, gotta run now) |
| 20:20 | gsnedders | guesses something totally illogical, thus doesn't guess |
| 20:22 | <gsnedders> | (Actually, I know it is something totally illogical: if that weren't the case, Hixie wouldn't be asking.) |
| 20:22 | <Hixie> | you're wrong |
| 20:22 | <gsnedders> | Sod. |
| 20:22 | <Hixie> | it is not one thing totally illogical |
| 20:22 | <Hixie> | it is THREE things totally illogical |
| 20:22 | <Hixie> | depending on the browser |
| 20:22 | <Hixie> | HTMLSelectElement, HTMLSpanElement, or HTMLElement |
| 20:22 | <annevk3> | HTMLElement, HTMLSpanElement, and HTMLSelectElement are not that illogical |
| 20:23 | <Hixie> | given that keygen should be exposing .disabled, they are |
| 20:23 | <annevk3> | you win :) |
| 20:24 | <annevk3> | the tree it gives in the DOM in Firefox/WebKit is also funny |
| 20:25 | <Hixie> | firefox just treats keygen as a magic macro in the parser, like <isindex> |
| 20:26 | gsnedders | realizes he is procrastinating, again |
| 20:26 | <Hixie> | but webkit actually creates a <select> element even for document.createElement('keygen') |
| 20:26 | <annevk3> | this will bite hsivonen |
| 20:27 | <annevk3> | (Opera doesn't actually expose .disabled) |
| 20:27 | <gsnedders> | (The version of U2's "The Fly" on "U2 Live from Boston" is awesome.) |
| 20:27 | <Hixie> | oh this is rich! guess what the return value of document.createElement('keygen').childNodes.length is |
| 20:28 | <gsnedders> | 2? |
| 20:28 | <Hixie> | per DOM Core, it cannot be anything but 0 |
| 20:28 | <Hixie> | but webkit makes it 3 |
| 20:28 | <gsnedders> | I was only one out! |
| 20:41 | <tantek> | hsivonen, thanks for another laugh. your bug report elicited some quite (untintended I'm sure) humorous responses/requests. |
| 20:42 | <tantek> | e.g. "The specific step I would like to see happen is for HTML 5 to mandate namespace |
| 20:42 | <tantek> | well-formedness and require draconian error handling." LOL! |
| 20:42 | <Hixie> | it's not clear to me what elharo meant by that |
| 20:42 | <Hixie> | the literal interpretation is so obviously not going to work that i can only assume i misunderstood it |
| 20:43 | <tantek> | also, referring to "text/html" as "one special case" (same comment in bug thread) |
| 20:43 | <tantek> | it's always nice when people make it quite clear how out of touch they are with real world web development/deployment/maintenance. |
| 20:45 | <annevk3> | hmm, Opera <keygen> has more event handler attributes so it does have some differences from e.g. <span> |
| 20:46 | <Hixie> | if you think that's fun you should see roy's comments on ietf-http-wg |
| 20:46 | <Hixie> | about how web browsers are but a minor part of the http ecosystem and that their needs can basically be dismissed since they're not that important on the global scale of things |
| 20:47 | <tantek> | Hixie, URL? that sounds worth the read |
| 20:49 | tantek | is collecting URLs to expand the documentation of why/how namespaces have failed on the web. |
| 20:49 | <annevk3> | FYI: http://wiki.whatwg.org/wiki/Namespace_confusion |
| 20:50 | <Hixie> | threat starting here: http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/thread.html#msg290 continuing here http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/thread.html#msg0 |
| 20:50 | <Hixie> | thread, even |
| 20:50 | <annevk3> | amusing typo |
| 21:00 | <tantek> | annevk3 - indeed - have seen it and am documenting here (cross-linked) http://microformats.org/wiki/namespaces-considered-harmful |
| 21:00 | <tantek> | recently found and added this: http://www.xml.com/pub/a/2004/07/21/dive.html |
| 21:01 | <tantek> | worth reading. note how old it is. |
| 21:04 | <Philip`> | http://google.com/codesearch/p?hl=en#J7osgojbryc/src/java/org/web3d/x3d/jaxp/X3DSAVAdapter.java&q=X3DSAVAdapter&l=847 is fun |
| 21:05 | <Philip`> | if(!space.equals("xsd")) etc |
| 21:06 | <Philip`> | (Xj3D is the closest thing to an 'official' implementation of X3D) |
| 21:32 | <tantek> | Philip', nice example. I've added it to http://microformats.org/wiki/namespaces-considered-harmful#namespaced_content_has_failed . I wonder how many such examples could find by using google code search to look for similar string prefix literal instances/compares with common namespace prefix usages. |
| 21:43 | <annevk3> | we should somehow deal with the JavaScript versioning issue |
| 21:43 | <annevk3> | https://bugzilla.mozilla.org/show_bug.cgi?id=487070 |
| 21:43 | <annevk3> | otherwise it starts leaking all over the place |
| 21:44 | <annevk3> | (I don't have a proposal :/) |
| 21:47 | <gsnedders> | To what extent is form@method followed? |
| 21:47 | <gsnedders> | Are only certain methods allowed? |
| 21:48 | <jgraham> | annevk3: Yeah, we totlly need a good solution for that |
| 21:51 | <jgraham> | It seems like in the short term Mozilla could do something like mozImportScripts but even ES5 vs ES3 needs a solution |
| 21:53 | <annevk3> | gsnedders, yes, with GET as fallback |
| 21:53 | <gsnedders> | That's what I thought. |
| 21:53 | <annevk3> | gsnedders, RTFS |
| 21:53 | <gsnedders> | annevk3: That doesn't mean we have interop on it now. |
| 21:54 | <gsnedders> | (I don't care about TFS, I care about what is shipping) |
| 21:54 | jgraham | was reading S as "Source" |
| 21:54 | <annevk3> | hehe, my answer works either way :p |
| 21:55 | <jgraham> | annevk3: You work for a proprietary browser company :) |
| 21:55 | <annevk3> | gsnedders, I suspect they follow the spec, but you'd have to test to be sure |
| 21:56 | <annevk3> | jgraham, I didn't say it was easy :p |
| 21:57 | <jgraham> | step 1: accept a job as a developer |
| 21:58 | <jgraham> | step 2: leave |
| 21:58 | <jgraham> | step 3: accept a MS job that gives you access to the IE source |
| 21:58 | <jgraham> | Seems easier to just ask really |
| 21:58 | <sayrer> | tantek, you might want to look at <o:p> for your namespace document |
| 22:06 | <sicking> | Hixie, re doc.write() |
| 22:06 | <sicking> | Hixie, that is not compatible with what at least firefox does. In a fairly catastrophicly incompatible way |
| 22:07 | <sicking> | Hixie, is that what IE does? |
| 22:09 | <Hixie> | sicking: as far as i can tell, the spec matches what Firefox does |
| 22:09 | <Hixie> | sicking: and what IE does |
| 22:09 | <Hixie> | sicking: (with some minor edge case exceptions that are unlikely to be hit in practice) |
| 22:09 | <sicking> | Hixie, in firefox if you use document.write while the document is still loading, from for example a setTimeout, we do not wipe the current doc |
| 22:10 | <sicking> | Hixie, we insert into the stream, whereever that happens to be |
| 22:11 | <Hixie> | ah you are correct, i just looked at my notes |
| 22:11 | <Hixie> | firefox does something ridiculous (rewind the tokeniser if half-way through a token, etc) |
| 22:12 | <Hixie> | so i dismissed firefox's behavior as something nobody would rely on |
| 22:12 | <sicking> | Hixie, indeed. Firefox is a guaranteed race condition |
| 22:12 | <sicking> | Hixie, does IE wipe the doc? |
| 22:12 | <Hixie> | yes |
| 22:12 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/level0/write/007.html |
| 22:12 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/level0/write/008.html |
| 22:13 | <sicking> | Hixie, so i'm a little scared to implement that, given how catastrophically things fail for gecko-specific content |
| 22:13 | <sicking> | Hixie, would prefer to make it a no-op instead |
| 22:14 | <Hixie> | i'll make this a no-op if you're willing to change the inner-window outer-window thing to what IE does. :-) |
| 22:14 | <sicking> | what does IE do? |
| 22:14 | <Hixie> | throw an exception if you run script in a window that's not active |
| 22:14 | <sicking> | not always |
| 22:15 | <Hixie> | my comment wasn't really a serious proposal |
| 22:15 | <sicking> | i know |
| 22:15 | <Hixie> | my point is that we can't just never do what IE does |
| 22:15 | <sicking> | agreed, but don't we have a lot of IE cruft in there? |
| 22:15 | <Hixie> | not really |
| 22:15 | <sicking> | like innerHTML, offsetLeft, XMLHttpRequest |
| 22:15 | <Hixie> | only innerHTML of those is in HTML5 |
| 22:16 | <Hixie> | and it's specced to match firefox |
| 22:16 | <Hixie> | not IE |
| 22:16 | <Hixie> | i don't really see why doing it the way IE does here is a bad thing |
| 22:16 | <Hixie> | it seems to be what everyone else does |
| 22:16 | <Hixie> | even firefox does it in most cases, just not timeouts |
| 22:17 | <Hixie> | e.g. from an onload="" it'll blow away the doc, no? |
| 22:17 | <sicking> | anything after DOMContentLoaded |
| 22:17 | <sicking> | not at all based on where it's called from, only when |
| 22:17 | <sicking> | so onmouseout, xhr.readystatechange, setInterval, etc, are all the same |
| 22:18 | <sicking> | i would be fine with trying to do what the spec says though |
| 22:18 | <Hixie> | if there is actual content that this breaks, then i'd be glad to consider it, but realistically speaking i imagine other browsers would be just as scared of making it a no-op |
| 22:18 | <sicking> | it seems very unlikely that someone relies on current behavior, other than through bugs |
| 22:18 | <sicking> | true |
| 22:18 | <sicking> | sure, lets do this and if we find pages that break we can reeval |
| 22:19 | <Hixie> | cool |
| 22:49 | <Hixie> | hsivonen is going to love <keygen>. </sarcasm> |
| 22:51 | gsnedders | takes a deep breath |
| 22:52 | <gsnedders> | (and then proceeds as in the "Any other end tag" section below) |
| 23:27 | <Hixie> | anyone know what opera supports when it comes to <keygen>? dsa? pqg? keyparams? |
| 23:27 | <Hixie> | annevk3? |
| 23:29 | <annevk3> | I think type="pkcs10" is an extension we have |
| 23:30 | <annevk3> | Yngve e-mailed you with details |
| 23:30 | <annevk3> | Not archived unfortunately but I guess that doesn't really matter |
| 23:32 | <Hixie> | his e-mail didn't seem to cover pqg/keyparams |
| 23:32 | <Hixie> | does that mean opera doesn't support them? |
| 23:33 | <annevk3> | It means I don't know |
| 23:33 | <annevk3> | sorry |
| 23:34 | <Hixie> | any chance you can find out? :-) |
| 23:34 | Hixie | considers dropping keygen after all |
| 23:34 | <Philip`> | What's wrong with testing and reverse-engineering? :-) |
| 23:35 | <Hixie> | i have no idea what to test or how |
| 23:35 | <Philip`> | Look at the specification to see what it's meant to do, and then just see if it does that or not |
| 23:36 | <Hixie> | what is this specification you speak of |
| 23:37 | <Philip`> | Well, maybe it's not so much a specification as an opportunity for a specification |
| 23:37 | <Philip`> | which is close enough |
| 23:38 | <annevk3> | Hixie, any chance you can reply and ask yourself? I understand less of this than you |
| 23:39 | <Hixie> | Philip`: until i looked at the gecko source code, i had no idea that there was a keyparams attribute at all, it's not documented anywhere |
| 23:39 | <Hixie> | Philip`: and until i saw an obscure e-mail on the topic in some archives, i didn't know that "ec" was a valid keytype |
| 23:39 | <Hixie> | Philip`: i have no idea how to reverse engineer what opera does short of asking them |
| 23:39 | <Hixie> | annevk3: yeah, probably will |
| 23:40 | <Hixie> | annevk3: basically all i'm looking for is a list of all the attributes and values that do something on keygen |
| 23:40 | <Hixie> | annevk3: ideally with some documentation as to what they do and what their format is |
| 23:40 | <annevk3> | there is http://web.archive.org/web/20070401073244/wp.netscape.com/eng/security/comm4-keygen.html |
| 23:40 | <annevk3> | but it's not that useful |
| 23:42 | Philip` | supposes it can be tricky to reverse-engineer a feature whose specific purpose is to produce results that cannot be reverse-engineered even with all the computing power in the world |
| 23:43 | <olliej> | Philip`: heheh |
| 23:43 | <annevk3> | https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag has no documentation on the Gecko extension either |
| 23:48 | <Hixie> | lol |
| 23:48 | <Hixie> | after tracing this code very carefully all the way through to figure out how gecko uses the pqg attribute for dsa keys |
| 23:49 | <Hixie> | and going through multiple quite obscure and poorly documented codepaths |
| 23:49 | <Hixie> | i find this: |
| 23:49 | <Hixie> | 605 case CKM_DSA_KEY_PAIR_GEN: |
| 23:49 | <Hixie> | 606 // XXX Fix this! XXX // |
| 23:49 | <Hixie> | 607 goto loser; |
| 23:49 | <Hixie> | they don't support dsa at all! |
| 23:52 | <Hixie> | and i have no way to tell if changing an attribute value changes the result |
| 23:52 | <Hixie> | since the result is PSEUDORANDOM BY DESIGN |
| 23:52 | <Hixie> | gah |
| 23:52 | <olliej> | Hixie: keygen should generate a random 16bit value that gets used character by character using efficient xor encryption of utf16 data :D |
| 23:52 | <Hixie> | i hate <keygen> |
| 23:52 | <olliej> | Hixie: nice and easy to spec out |
| 23:53 | <olliej> | Hixie: and efficient |
| 23:53 | <olliej> | ;D |
| 23:53 | <Hixie> | olliej: i don't think we'd get many interoperable implementations |
| 23:53 | <olliej> | Hixie: of xor encryption? it's one line, even browser developers cna't screw up compatibility for that |
| 23:53 | <olliej> | surely :D |
| 23:53 | <Hixie> | oh i don't think complexity is why it'd be ignored... |
| 23:55 | <olliej> | Hixie: oh you mean there just wouldn't be many implementations at all |
| 23:55 | <olliej> | vs. multiple incompatible ones |
| 23:55 | <Philip`> | You could try patching the source code to remove the randomness, to make it easier to test |
| 23:55 | Philip` | refrains from making any comments about Debian |
| 23:55 | <olliej> | personally i'm for speccing out keygen based on xor encryption |
| 23:55 | <olliej> | but mostly because i want to see the followup whatwg mail from security people :D |
| 23:56 | <olliej> | i suspect it would be entertaining |