| 01:01 | <theMadness> | Is there a way to get OpenID additional headers to validate in html5? |
| 01:09 | <theMadness> | http-equiv is enumerated, is it possible to suggest other values? |
| 01:31 | <Hixie> | svn.whatwg.org is back |
| 05:55 | <JonathanNeal> | hi |
| 06:57 | <hsivonen> | gsnedders: IIRC, at least as of JDK 1.4.2, you needed to wrap an InputStreamReader around an FileInputStream and never use FileReader to get sane decoding behavior |
| 06:57 | <hsivonen> | gsnedders: when a JDK API says it uses the platform's encoding, run away, run away fast |
| 06:59 | <hsivonen> | sigh. http://icantbelieveitsnotflash.com/dhtml-lemmings uses Flash for the video |
| 06:59 | <hsivonen> | FAIL |
| 07:15 | <MikeSmith> | hsivonen: http://code.google.com/p/jing-trang/issues/detail?id=91 |
| 07:19 | <hsivonen> | MikeSmith: that's odd. I haven't touched the branch recently |
| 07:19 | <MikeSmith> | hsivonen: I think it's been that way for quite a while |
| 07:19 | <hsivonen> | oh |
| 07:20 | <MikeSmith> | since r2224 at least |
| 07:20 | <hsivonen> | so the build completes? |
| 07:20 | <MikeSmith> | the core build does, yeah |
| 07:20 | <MikeSmith> | but not that dist target |
| 07:20 | <MikeSmith> | oh |
| 07:20 | <MikeSmith> | yeah, the code build completes |
| 07:21 | <MikeSmith> | but then if you run jing built from it, you get that same error |
| 07:21 | <MikeSmith> | at runtime |
| 07:21 | <hsivonen> | interesting |
| 07:21 | <MikeSmith> | but only if you are validating against a Schematron schema |
| 07:21 | <hsivonen> | but V.nu works? |
| 07:21 | <MikeSmith> | yup |
| 07:21 | <MikeSmith> | I guess because it's not actually doing schematron checking using jing |
| 07:22 | <hsivonen> | MikeSmith: interesting |
| 07:22 | <hsivonen> | MikeSmith: if you give it a random .sch file, it should |
| 07:22 | <MikeSmith> | ah |
| 07:22 | <hsivonen> | including the XHTML 1.0 preset |
| 07:22 | <MikeSmith> | OK |
| 07:22 | <hsivonen> | aside: there's going to be an interesting merge hell some day merging the trunk into the branch... |
| 07:23 | <MikeSmith> | yeah, I was going to ask you about that too |
| 07:23 | <MikeSmith> | I think it'd be better to move the branch into the trunk.. |
| 07:23 | <MikeSmith> | s/move/merge/ |
| 07:23 | <hsivonen> | I've been waiting for George Bina's improved error message patch to make it to the trunk |
| 07:23 | <MikeSmith> | I see George just released something on the 11th |
| 07:24 | <hsivonen> | Can't move to the trunk unless James Clark & George Bina are OK with the added API surface V.nu needs |
| 07:25 | <hsivonen> | In particular, there wasn't any conclusion about how to communicate the error message identity to V.nu in a way that everyone approved of |
| 07:25 | <hsivonen> | the datatypeexceptions need to be passed to V.nu front end, too |
| 07:27 | <MikeSmith> | hsivonen: I see |
| 07:28 | <MikeSmith> | I looked through the commit logs on the trunk and see there's been a lot of changes since you branched |
| 07:28 | <hsivonen> | MikeSmith: are any of them must-haves for V.nu? |
| 07:28 | <MikeSmith> | e.g., James added support to the schematron validator for emitting column numbers |
| 07:28 | <hsivonen> | MikeSmith: the V.nu column has that |
| 07:28 | <hsivonen> | I added it to the 2003 Jing |
| 07:29 | <MikeSmith> | hsivonen: I guess I didn't see anything on the trunk that seemed like a must for v.nu |
| 07:29 | MikeSmith | goes back to look |
| 07:29 | <hsivonen> | MikeSmith: when George Bina lands the patch that makes the errors explain *why* validation failed, I definitely want to merge |
| 07:30 | <MikeSmith> | OK |
| 07:30 | <MikeSmith> | hsivonen: hmm, here's one interesting thing: OASIS catalog support |
| 07:31 | <hsivonen> | MikeSmith: is that for DTDs? |
| 07:31 | <MikeSmith> | can't tell from the commit messages |
| 07:31 | <MikeSmith> | r2303 and r2306 |
| 07:32 | <hsivonen> | MikeSmith: looks like a generic URI rewriting scheme |
| 07:32 | <MikeSmith> | yeah |
| 07:47 | <theMadness> | Augh, http://hsivonen.iki.fi/rdf-competition/ |
| 07:48 | <theMadness> | It makes no sense, then I read Tim Berners-Lee and think "well, he said it, it should make sense", but then again it doesn't. And... the pain! |
| 07:50 | <MikeSmith> | theMadness: hey. I've been meaning to respond to your tweet |
| 07:50 | <MikeSmith> | about indicators for new elements |
| 07:50 | <MikeSmith> | the TOC of the current draft of my markup doc does already show that |
| 07:51 | <MikeSmith> | hsivonen: does column-number reporting for schematron validation on the validator-nu branch require Saxon 9? |
| 07:52 | <theMadness> | MikeSmith, for OpenID? |
| 07:52 | <theMadness> | http-equiv meta? |
| 07:53 | <MikeSmith> | theMadness: I meant for this tweet: http://twitter.com/theMadness/status/5925930242 |
| 07:54 | <MikeSmith> | I don't understand the reference to OpenID.. |
| 07:54 | <theMadness> | Ah right. |
| 07:54 | <theMadness> | I tweeted about that last night. |
| 07:55 | <theMadness> | OpenID providers require some http headers, and most implementations send them out with meta http-equiv tags, which tends to prevent the html5 validation. |
| 07:55 | <hsivonen> | MikeSmith: it requires a version of SAXON that can report line numbers, so the latest of the 9 series |
| 07:55 | <hsivonen> | MikeSmith: earlier I used my own fork of SAXON, too |
| 07:55 | <MikeSmith> | OK |
| 07:56 | <hsivonen> | theMadness: please file a spec bug about OpenID conflict |
| 07:57 | hsivonen | notes that OpenID libraries don't tend to use real HTML parsers and can fail with valid HTML 4 |
| 07:58 | <hsivonen> | (Anne discovered this when he tried to make his OpenID page omit centain optional tags) |
| 07:58 | <hsivonen> | like <html> and <head> |
| 07:58 | <hsivonen> | (cue Stack Overflow regexp rant) |
| 08:11 | <theMadness> | MikeSmith, I got what you mean, but I was hoping for a summary list. |
| 08:12 | <MikeSmith> | ah, I see |
| 08:14 | <MikeSmith> | theMadness: http://dev.w3.org/html5/html4-differences/#new-elements has a very good summary list |
| 08:16 | <theMadness> | Right. |
| 08:16 | <theMadness> | Man, HTML5 has a truckload of different docs. |
| 08:16 | <theMadness> | That's not a good thing. |
| 08:17 | <hsivonen> | theMadness: various dissenters disagree with you on that one. |
| 08:18 | <theMadness> | I'm trying to be "just a user" here. |
| 08:18 | <theMadness> | And there's quite a bunch of stuff I have to keep track. |
| 08:18 | <theMadness> | By the way, what happened to Last Call? |
| 08:19 | <hsivonen> | theMadness: people who care about Architecture and spec purity want to have a larger number of smaller docs |
| 08:20 | <hsivonen> | theMadness: the HTML WG chairs allowed the deadline to go by because there are open ISSUEs in the ISSUE tracker |
| 08:20 | <theMadness> | :( |
| 08:21 | <theMadness> | But I'm tired of idiots yelling "NOT A STANDARD". |
| 08:24 | <hsivonen> | theMadness: the Process allows dissenters to filibuster the Last Call by raising ISSUEs |
| 08:25 | <theMadness> | AGH. US politics metaphor. |
| 08:25 | <theMadness> | My achille's heel. |
| 08:26 | <theMadness> | Are issues serious or are they "Issue #42344: Hixie is a big doo doo head"? |
| 08:26 | hsivonen | thought filibustering was a more general parliamentary tactic than being U.S.-specific, but the only English word I know for it is the en-US word |
| 08:27 | <theMadness> | Filibustering isn't present in all the systems. |
| 08:27 | <theMadness> | Some systems don't allow people to delay in such a stupid way. One of the few things in the itlaian parliament that makes sense. |
| 08:28 | <hsivonen> | theMadness: you can judge the seriousness yourself here: http://www.w3.org/html/wg/tracker/issues/ |
| 08:28 | <theMadness> | 88, I expected more. |
| 08:29 | <hsivonen> | theMadness: I expect there to be more in due course as more bugs get WONTFIXed |
| 08:34 | <theMadness> | That is where I should place the bit about the OpenID tags? |
| 08:34 | <theMadness> | <meta http-equiv="X-XRDS-Location" | <meta http-equiv="X-Yadis-Location" ? |
| 08:35 | <hsivonen> | theMadness: no, you start with http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG |
| 08:36 | <hsivonen> | theMadness: then if Hixie WONTFIXes it and someone disagrees, it gets turned into an ISSUE |
| 08:36 | <hsivonen> | eww. those are X- headers |
| 08:36 | <theMadness> | Yep. |
| 08:36 | <hsivonen> | are those OpenID 2.0-only? |
| 08:36 | <theMadness> | I have no flippin' clue. |
| 08:37 | <hsivonen> | it's going to be politically hard to make those conforming while keeping X-UA-Compatible non-conforming |
| 08:38 | <theMadness> | That's for IE right? |
| 08:39 | hsivonen | wonders why extenders of HTML like to mint X- pseudo-headers instead of just squatting non-X meta *names* |
| 08:39 | <hsivonen> | theMadness: yes |
| 08:39 | <theMadness> | hsivonen, I have no idea. |
| 08:40 | <theMadness> | I also don't know why the diso dude didn't just use header() for that. (wordpress openid plugin). |
| 08:40 | <hsivonen> | theMadness: so real HTTP headers would work? |
| 08:41 | <theMadness> | I have no idea, but isn't the idea behind http-equiv to emulate a HTTP header when there's no way to send the actual header? |
| 08:42 | <hsivonen> | theMadness: in theory, yes, but it's not always used that way |
| 08:42 | <hsivonen> | (e.g. Refresh) |
| 08:43 | <theMadness> | This is stupid. Like OpenID isn't meeting enough resistance. |
| 08:44 | hsivonen | doesn't know enough about OpenID 2.0 and XRDS to have an opinion on whether resisting OpenID 2.0-isms is good or bad |
| 08:44 | <hsivonen> | (OpenID 1.0 seems good to me, though) |
| 08:45 | hsivonen | notes that the TAG seemed to dislike XRIs |
| 08:46 | <hsivonen> | but I tend to agree that making OpenID stuff non-conforming is stupid |
| 08:46 | <hsivonen> | even though I have very little sympathy in general for spec writers who cram their extensions into http-equiv instead of name=foo |
| 08:48 | <theMadness> | you mean <meta XRDS-Location="url"> right? |
| 08:51 | <hsivonen> | I mean <meta name="xrds-location" content="url"> |
| 08:51 | <theMadness> | Ah. |
| 10:36 | <robertnyman> | Hello, dear WHATWG |
| 10:37 | <robertnyman> | Just wanted to mention that I wrote a blog post about the syntax options in HTML5, and get general feedback on how we can achieve/maintain HTML code quality: http://robertnyman.com/2009/11/27/the-html5-syntax-options-problem/ |
| 10:37 | <robertnyman> | Feel free to chime in! :-) |
| 10:42 | <annevk2> | Hmm, not sure I want to enter another you were not using XHTML debate :) |
| 10:43 | <annevk2> | robertnyman, the reason uppercase etc. is allowed is not because of CMSs etc. it is because HTML always allowed that |
| 10:43 | <annevk2> | robertnyman, the reason /> and xmlns are allowed is because of CMSs etc. |
| 10:44 | <robertnyman> | Hmm.. |
| 10:44 | <annevk2> | (initially /> and xmlns were not allowed) |
| 10:45 | <annevk2> | you can also do <div> test </DIv> btw |
| 10:45 | <annevk2> | and other weird variations :) |
| 10:45 | <robertnyman> | I understand about the debate, but I wish/hope it it will be beyond what people prefer, and rather options we have to make it easier for people to use a more strict syntax (HTML and XHTML alike) |
| 10:46 | <robertnyman> | I thought the uppercase was also due to content generated from WYSIWYG editors based on contenteditable in IE |
| 10:46 | <Philip`> | I thought the /> and xmlns things were largely allowed to ease migration to HTML5 for people who were fooled by the validator into thinking they were writing proper XHTML |
| 10:46 | <annevk2> | in the first paragraph of "Available syntax options" the example seems wrong |
| 10:46 | <annevk2> | Philip`, yeah, it was motivated by e.g. the adoption of WP |
| 10:46 | <robertnyman> | And that case-variation is something I just don't want to know about :-) |
| 10:47 | <annevk2> | (i.e. it should end in /> to make sense) |
| 10:48 | <jgraham> | robertnyman: Your point of view seems predictaed on the assumption that a desire for more strict syntax is not merely a preference |
| 10:48 | <robertnyman> | Absolutely, thanks! |
| 10:48 | <robertnyman> | Missed the slash there (ashamed) |
| 10:48 | <jgraham> | *predicated |
| 10:49 | <annevk2> | I certainly have some kind of preference when writing HTML |
| 10:49 | <annevk2> | though it tends to differ per file |
| 10:50 | <robertnyman> | You see, the things you express here; Anne with the background for some choices, and jgraham about what, if any, preference we should have would make GREAT blog comments :-) |
| 10:51 | <Philip`> | robertnyman: Do you want something like the "Profile" option on http://validator.nu/ so you can choose what coding conventions you want to check? |
| 10:52 | <robertnyman> | To answer about strict syntax: my personal experience at least, as a consultant, doing audits etc, is that a certain strictness has been far more optimal to achieve code consistency, and also code handover between developers |
| 10:52 | <annevk2> | when people write blog posts about HTML5 they should just add pointers to the #whatwg IRC logs for related discussion :) |
| 10:52 | <annevk2> | bound to be discussed here |
| 10:52 | <robertnyman> | @Philip Yes |
| 10:53 | <robertnyman> | Well, it is, but my personal experience is that people prefer blog articles and comments which are specific to a certain topic |
| 10:53 | <robertnyman> | IRC is great and with logs, but there is also a certain amount of noise, possible lack of findability etc |
| 10:53 | <Dashiva> | annevk2: Maybe they need a lookup service to find the relevant logs |
| 10:53 | <robertnyman> | IMHO |
| 10:54 | <annevk2> | Dashiva, yeah |
| 10:54 | <annevk2> | robertnyman, definitely |
| 10:54 | <annevk2> | robertnyman, the issue is that commenting on blogs is too much effort :) |
| 10:54 | <robertnyman> | Ha ha, I agree :-) |
| 10:54 | <annevk2> | since you need to keep track of your comment to see if other people reply, etc. |
| 10:54 | <annevk2> | maybe Wave will solve this |
| 10:54 | <robertnyman> | I see your point |
| 10:55 | <robertnyman> | I just like the openness of a blog, though, in the sense that it is not the log or similar of an organization |
| 10:55 | <robertnyman> | It is, hopefully, complteley stand-alone |
| 10:55 | <robertnyman> | Hence, in people's eyes, unbiased |
| 10:55 | <robertnyman> | I do offer RSS feeds for comments per specific post as well :-) |
| 10:56 | <annevk2> | unbiased in what way? |
| 10:56 | <robertnyman> | I'm not saying WHATWG is biased in the sense of just defending choices (or whatever), but in a number of developers' eyes, they prefer another location/channel than who's behind it |
| 10:57 | <robertnyman> | I.e. a blog post about what works in IE might be more true than a web page at microsoft.com |
| 10:57 | <robertnyman> | Sorry, might be more true IN THEIR EYES |
| 10:58 | <robertnyman> | Am I making sense here? :- |
| 10:58 | <robertnyman> | :-) |
| 10:59 | <Philip`> | You mean people trust random unverified strangers more than they trust people with experience and authority? Makes sense to me :-) |
| 11:00 | <robertnyman> | Ha ha! |
| 11:00 | <robertnyman> | Well, isn't it true in some sense? :-) |
| 11:00 | <jgraham> | Oh I thought robert just meant that people just random unverified strangers more than they trust msdn ;) |
| 11:00 | <robertnyman> | Ok, ok, forget it, this will get dangerous :-) |
| 11:00 | <Philip`> | MSDN is great |
| 11:01 | <Philip`> | It taught me yesterday that IE supports a .vrml property on HTML objects |
| 11:01 | <Philip`> | http://msdn.microsoft.com/en-us/library/dd347031(VS.85).aspx - not exactly enough information for someone to make an interoperable implementation, sadly |
| 11:02 | <robertnyman> | Actually, when it comes to discussions, I see such a majority moving to Twitter instead of IRC, blog comments etc |
| 11:02 | <Philip`> | robertnyman: Danger is good |
| 11:02 | <robertnyman> | @Philip, It might be, yes :-) |
| 11:02 | Philip` | prefers a communication medium where it is possible to express coherent trains of thought |
| 11:02 | <theMadness> | robertnyman, a validation tool that validates not against a spec but against a different set of rules can be easily done. |
| 11:03 | <annevk2> | Philip`, that explains your persistent presence on IRC! |
| 11:03 | <robertnyman> | Also, regarding the validator, and I think it is also vital that the one hosted at W3C will have all options (not solely validator.nu), because most people will go there |
| 11:04 | <jgraham> | annevk2: Rather it presumes a persistent presence |
| 11:04 | <robertnyman> | @theMadness Sounds good - here's for hoping! |
| 11:04 | <theMadness> | Err, not by me or by the w3c. |
| 11:04 | <theMadness> | I meant by anyone. |
| 11:04 | Philip` | notes that he rarely actually expresses coherent trains of thought, but likes it to be possible |
| 11:04 | <theMadness> | I'm not a member of any WG. |
| 11:05 | <theMadness> | My main concern is provide a completely dumbfounded junior webdev perspective to the spec writers. :P |
| 11:06 | <annevk2> | theMadness, you're not on the WHATWG list? |
| 11:06 | <theMadness> | Nope. |
| 11:06 | <annevk2> | fair enough |
| 11:07 | <theMadness> | I should stop writing with capital letters and periods, it makes me look like I actually know stuff. |
| 11:08 | <annevk2> | well, your nick is theMadness... :p |
| 11:08 | <hsivonen> | robertnyman: would you want the spec to dictate an indent style, too? (not a rhetorical question) |
| 11:08 | <theMadness> | annevk2: there's a 'madness' guy who lurks around, too. |
| 11:08 | <annevk2> | hsivonen, I'd also like it to check whitespace between attributes and such :) |
| 11:09 | <theMadness> | Dare I say it? |
| 11:09 | <theMadness> | Tidy. |
| 11:09 | <annevk2> | hsivonen, and sometimes I'd like it to check 76-80 character line-wrapping depending on whether I edit something I have to read a unified diff off |
| 11:09 | <annevk2> | hsivonen, except for constructs that are ok to be longer than 76-80 characters |
| 11:10 | <annevk2> | but I doubt I'll ever get that functionality automatically |
| 11:10 | <annevk2> | unified diff will go away first :) |
| 11:10 | <hsivonen> | robertnyman: as for the style options feature on V.nu in general. Sam volunteered to implement it if the HTML5 Super Friends volunteered to spec it |
| 11:11 | <robertnyman> | hsivonen: Well, the indentation debate is pretty much never-ending, isn't it? But no, I don't think it should be in the spec |
| 11:11 | <hsivonen> | robertnyman: as far as I know, the Super Friends haven't followed up |
| 11:11 | <robertnyman> | For me, indentation is about style guides in the team |
| 11:11 | <theMadness> | Don't say superfriends. CSS squirrel ticks me off. :/ |
| 11:11 | <hsivonen> | robertnyman: aren't tokenizer-level details that don't even leak to the DOM even less checking-worthy than indentation? |
| 11:11 | <robertnyman> | Which is what HTML syntax could be too, but it's nice to have a validator for that |
| 11:12 | <hsivonen> | I should probably ping Sam and ask what the status of the syntax profile thingy is |
| 11:12 | <robertnyman> | Interesting about the SuperFriends, we'll have to see about that |
| 11:12 | <annevk2> | hsivonen, interesting thought |
| 11:12 | Philip` | remembers an old 2D platform game with a supersquirrel |
| 11:12 | <hsivonen> | and in any case, I should probably disable it on V.nu, because some people have already thought that the feature actually works as labeled |
| 11:12 | <robertnyman> | I think the details are interesting, as in comparison to what developers had before, and in line with the teaching of more strict code etcx |
| 11:13 | <annevk2> | from a DOM-perspective checking whitespace between tags makes total sense |
| 11:14 | <hsivonen> | annevk2: indeed, from an operational perspective, checking for whitespace issues makes more sense than checking for, e.g., tag case. |
| 11:15 | <hsivonen> | robertnyman: I think concern about this topic will subside once people come to terms with the truth about XHTML-as-text/html |
| 11:16 | <robertnyman> | Maybe |
| 11:16 | <hsivonen> | robertnyman: that said, my top priority as far as non-normative style issues go is reporting implied tags |
| 11:16 | <jgraham> | But people don't really care about how things actually work. They care about percieved surface syntax |
| 11:17 | <hsivonen> | jgraham: yeah. I suck at marketing. Maybe I should start handing out badges, too. :-( |
| 11:17 | <robertnyman> | But aren't you maybe overlooking what it's like for developers writing code, striving for consistent HTML styles? It might not matter for rendering, but it might matter a lot for teaching, documentation, team handover etc |
| 11:17 | <Philip`> | http://www.copysoft.com/back_to_the_forest.php - hooray, found it |
| 11:17 | <hsivonen> | robertnyman: I think consistent style belongs into the auto-reformat feature of a text editor |
| 11:17 | <hsivonen> | robertnyman: like Eclipse keeps my Java code style consistent |
| 11:18 | <hsivonen> | not javac |
| 11:19 | <robertnyman> | Right - personally I prefer a stand-alone tool for that. But isn't there a risk then that people will think that the validator doesn't really validate much, if you get my drift? |
| 11:19 | <hsivonen> | robertnyman: anyway, once I've implemented implied tag reporting, I intend to look into reporting unquoted attributes |
| 11:19 | <hsivonen> | robertnyman: (and implied tag reporting has to wait on some higher-priority Firefox work) |
| 11:19 | <robertnyman> | I understand, and I'm glad to hear that you will look at it :-) |
| 11:19 | <hsivonen> | robertnyman: reporting tag case is my lowest-priority item in this area |
| 11:20 | <robertnyman> | I understand. Personally, I'd say quotes on attributes are more important |
| 11:20 | <hsivonen> | robertnyman: on the contrary, it seems that occasionally the validator is perceived to validate too much |
| 11:21 | <hsivonen> | robertnyman: many times it's unease about it being *different* from what the W3C DTD validator did |
| 11:21 | <robertnyman> | Not if you ask me :-) |
| 11:21 | <Philip`> | hsivonen: You need to give out badges like http://www.qualidator.com/Wqm/en/TestWebsite/http_hsivonen.iki.fi/.aspx telling people the quality of their pages to three significant figures |
| 11:21 | <robertnyman> | Either way, please feel free to at least keep your eyes on the feedback at http://robertnyman.com/2009/11/27/the-html5-syntax-options-problem/ |
| 11:22 | <hsivonen> | robertnyman: if V.nu doesn't report something that the W3C DTD validator validating XHTML 1.0 reported, people are concerned that HTML5/V.nu isn't strict enough |
| 11:22 | <robertnyman> | Might be some indication on what devs think about it |
| 11:22 | <hsivonen> | robertnyman: when V.nu plugs a loophole in DTDs you could drive a truck through, there's always someone who is unhappy to become aware of an issue in their code |
| 11:22 | <robertnyman> | Yes, I believe that if it used to, for instance, validate quotes on attributes and now don't, they will feel something's missing |
| 11:23 | <adactio> | hsivonen: I can't overemphasise how much authors want linting options for HTML. I know it's technically not validating, but if people had the option to check for lowercase/quoted/self-closing, they would be *far* more eager to investigate HTML5. |
| 11:23 | <robertnyman> | Oh,a bsolutely |
| 11:23 | <robertnyman> | A quote I just read in a comment: "Fewer syntax options are simpler to learn, easier to validate, easier to parse and render and will make for more robust code which is more easily understood and tested." |
| 11:23 | <hsivonen> | adactio: I bet they don't really want lower case. They want canonical case. |
| 11:23 | <robertnyman> | From a developer's perspective |
| 11:24 | <hsivonen> | adactio: that is, I bet they don't want SVG-in-text/html camelCase stuff to be warned about if in lower case |
| 11:24 | <adactio> | hsivonen: Indeed. What they want are options e.g. "tell me if any elements are uppercase", "tell me if any elements are uppercase", "tell me if any elements aren't quoted". |
| 11:25 | <theMadness> | How about a simple check "xml compatibility" ? |
| 11:25 | <adactio> | sorry, meant "lowercase" in the second quote. |
| 11:25 | <hsivonen> | adactio: anyway, my take on those features is the same as around the time of Super Friends post |
| 11:25 | <Philip`> | theMadness: XML compatibility is not simple |
| 11:25 | <theMadness> | Which would make xhtml lovers squirm. |
| 11:25 | <theMadness> | Philip`, to achieve or to validate? |
| 11:25 | <adactio> | theMadness: but as hsivonen points out, that's just one example of a coding style. An all-uppercase coding style is equally valid. |
| 11:25 | <hsivonen> | adactio: basically, most stuff I want to offer eventually, but I have to get higher-priority Firefox stuff done first |
| 11:26 | <adactio> | ("valid" in a non-technical sense) |
| 11:26 | <Philip`> | theMadness: To understand what it means |
| 11:26 | jgraham | has no idea why anyone's desire to "investigate HTML5" should be coupled to the avalibility of tools that told them whether they accidentially held the shift key down whilst typing a tag name |
| 11:26 | <hsivonen> | adactio: and for the tag case checking item I don't yet have a solution that has a reasonable cost/benefit ratio |
| 11:26 | <theMadness> | adactio, just like having all the class names in pig latin. But you have to draw the line somewhere I guess. |
| 11:26 | <adactio> | hsivoven: Understood. I just wanted you to know how much this feature is desired. |
| 11:26 | <Philip`> | theMadness: Start by reading http://wiki.whatwg.org/wiki/HTML_vs._XHTML and then listing precisely what it means for an HTML document to have "xml compatibility" :-) |
| 11:27 | <hsivonen> | theMadness: in short, XML compatibility is not simple |
| 11:27 | <theMadness> | Philip`, to me it means be consumable by a simple xml reader. |
| 11:27 | <hsivonen> | theMadness: and people who say they want it usually only want it because they don't know the truth about what it entails |
| 11:27 | <gsnedders> | theMadness: It's hard to just make sure what you output is well-formed |
| 11:27 | <theMadness> | but I am apparently very misguided... |
| 11:27 | <Philip`> | theMadness: A simple XML reader can parse "<!DOCTYPE HTML><HTML><BoguS/></HTML>" just fine |
| 11:28 | <adactio> | jgraham: Sorry you don't understand it but there it is. People want lint tools. |
| 11:28 | <Philip`> | theMadness: so presumably you want more complex restrictions |
| 11:28 | <theMadness> | Tbh no. |
| 11:28 | <theMadness> | Maybe lowercase names/attributes. |
| 11:29 | <hsivonen> | adactio: anyway, if you'd like Sam to get some of this stuff done before I get to it, it would help if the Super Friends bothered to articulate what they *really* want on the level Sam requires |
| 11:29 | <theMadness> | But basically stuff that a dtd validator could easily validate. |
| 11:29 | <jgraham> | adactio: Oh clearly people want them. I just don't understand why they would be totally uninterested in any of the functional aspects of a technology unless it came packaged with tools to check for particular coding styles |
| 11:30 | <hsivonen> | theMadness: I think you don't *really* want lower case and instead want canonical case |
| 11:30 | <adactio> | hsivonen: what does this have to with Sam? We're not looking for changes to the spec, we're looking for features in a tool. |
| 11:30 | <theMadness> | Is there anything that is canonically uppercase? |
| 11:30 | <Philip`> | adactio: http://intertwingly.net/blog/2009/09/02/Polyglot-Validation |
| 11:30 | <theMadness> | But yeah, canonical case is right. |
| 11:31 | <hsivonen> | adactio: what Philip` said |
| 11:31 | <Philip`> | adactio: Sam was offering to patch the validator if he was told what was actually wanted |
| 11:31 | <jgraham> | adactio: I don't think people act in the same way for non-HTML technologies |
| 11:31 | <hsivonen> | theMadness: SVG-in-text/html has elements and attributes whose canonical case has upper case letters |
| 11:31 | <hsivonen> | theMadness: also one MathML attribute |
| 11:32 | <theMadness> | hsivonen, sure, I'm cool with whichever is the standard, no biggie. |
| 11:32 | <adactio> | hsivonen: I'll see if I can get test cases together. |
| 11:33 | <hsivonen> | patching the validator comes with the caveat, that I might reject patches related to case checking |
| 11:33 | <theMadness> | jgraham, that's because true programmer use them. |
| 11:33 | <Philip`> | jgraham: Non-HTML technologies are usually entirely new, whereas HTML5 is just a version update and you don't want serious tool regressions (like loss of XML-well-formedness checking) when updating |
| 11:33 | <hsivonen> | (because keeping the code base clean and performant is important, too) |
| 11:34 | <theMadness> | Unlike html, which is used by ... what's the canon there? untrue? false? noob? ... programmers. |
| 11:34 | <jgraham> | Philip`: I don't see how it is a "serious" tool regression |
| 11:34 | <hsivonen> | (if you can still call it clean with all the "NOCPP" stuff all over the place) |
| 11:34 | <jgraham> | and you can check if your markup is well formed by feeding it to an xml parser |
| 11:34 | <jgraham> | Which is rather trivial |
| 11:35 | <hsivonen> | (in fact, taking the time to patch the parser for case checking before discussing design is probably a bad way to do it) |
| 11:35 | <theMadness> | From a marketing standpoint it's sadly not trivial. |
| 11:35 | <adactio> | hsivonen: just for the record though, please note that we are *not* looking for a way to validate polyglot documents (a complicated task), just a way to check for canonical casing, quoted attributes, and (maybe) self-closing standalone elements. |
| 11:35 | <theMadness> | Ah the humanity. |
| 11:35 | <hsivonen> | adactio: quoted attributes is doable, self-closing is probably also doable |
| 11:36 | <adactio> | hsivonen: so canonical case is the biggest challenge? |
| 11:36 | <jgraham> | Philip`: (and also there are lots of incremental upgrades that will break tools e.g. Fortran 77 -> 90, C-C++, etc.) |
| 11:36 | <hsivonen> | adactio: the doability of the case stuff depends on coming up with a non-disruptive implementation |
| 11:36 | <hsivonen> | adactio: in terms of disruption to the code base, yes |
| 11:36 | <gsnedders> | adactio: The problem with canonical case is taht parsers normalize internally, and validators operate on parse trees normally |
| 11:36 | <adactio> | hsivonen: Understood. |
| 11:37 | <adactio> | gsnedders: Ah, I see. See validators aren't necessarily looking at the "raw" source, they're looking at something that has already been parsed. |
| 11:38 | <gsnedders> | adactio: Right, and for syntax errors they report back parse errors |
| 11:38 | <hsivonen> | adactio: the parser codebase tries to be at least 4 things at once |
| 11:38 | <adactio> | hsivoven: and if you throw lint options in there, it's trying to be 5 things I guess. :-) |
| 11:39 | <hsivonen> | adactio: 1) a parser suitable for validation, 2) a parser suitable for browsers, 3) a never-fatal-error-throwing parser for non-browser apps and 4) a streaming parser for non-browser apps |
| 11:40 | <hsivonen> | at this point, I don't want changes that would deoptimize performance in cases other than #1 |
| 11:40 | <hsivonen> | especially #2 |
| 11:41 | <adactio> | Hmm... I wonder if it wouldn't be better if a lint tool were completely separate (it could be built just using regular expressions) and then a separate tool could run one document through 1) the validator and 2) the lint tool before reporting back the results of both. |
| 11:41 | <Philip`> | Would you have to do something like do the case checking in the tokeniser (before it's normalised the tag names), so that it doesn't disrupt the rest of the code? (I guess that should be feasible since the required case is never context-dependent (I hope)) |
| 11:41 | <hsivonen> | adactio: no regular expressions! http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 |
| 11:42 | <hsivonen> | Philip`: it's context-dependent |
| 11:42 | <adactio> | hsivonen: even if it's just for a quick'n'dirty lint check? |
| 11:42 | <theMadness> | Wait, I was told that the mantra was that regexes couldn't parse xml/html. |
| 11:42 | <hsivonen> | Philip`: although I think it's never context-dependent and conforming |
| 11:42 | <theMadness> | Not decently at least. |
| 11:43 | <hsivonen> | Philip`: assuming <textArea> is zapped |
| 11:43 | <Philip`> | hsivonen: I was assuming non-conforming didn't matter (since the case error would be overridden by the invalid-name error) |
| 11:43 | <hsivonen> | (and <textArea> has always been zapped since before SVG 1.2 Tiny went to REC over formal objections) |
| 11:43 | <Philip`> | hsivonen: though I forgot about <textArea> |
| 11:44 | <hsivonen> | Philip`: probably the most reasonable implementation would be |
| 11:44 | <hsivonen> | 1) ignoring context |
| 11:44 | <adactio> | hsivonen: okay, so no regular expressions. ;-) But still, I think perhaps a lint tool would be better if it were separate from a validator (but that would still allow a single service to run a document through both). |
| 11:44 | <hsivonen> | 2) making the tokenizer not case fold first |
| 11:44 | <hsivonen> | 3) making the tokenizer case-check at the end of a name |
| 11:45 | <hsivonen> | 4) making the tokenizer case-fold at the end of the name after the check |
| 11:45 | <hsivonen> | and using some monstrosity equivalent to the C preprocessor for toggling this behavior ahead of compile time |
| 11:47 | <Philip`> | Rather than a preprocessor monstrosity, couldn't you do something like subclass the tokeniser and override the name-parsing functions and use the magic of virtual calls? |
| 11:47 | <hsivonen> | adactio: implementing a lint without a proper parser is a fool's errand |
| 11:48 | <hsivonen> | Philip`: possibly |
| 11:48 | <Philip`> | That seems the more Javaish way to vary functionality without using if()s |
| 11:49 | <hsivonen> | Philip`: currently in Java, every character goes through a method that is a no-op in the usual tokenizer and overridden in the error reporting subclass |
| 11:49 | <hsivonen> | Philip`: and inlined away in C++ |
| 11:49 | <hsivonen> | so it doesn't translate to a virtual in C++ |
| 11:49 | <adactio> | hsivonen: I think there's value in having something that works 80% of the time if the alternative is having nothing (which works 0% of the time) which is what authors have now (in terms of linting tools). |
| 11:49 | <Philip`> | Actually, why not just use if()s to enable the slightly-slower-but-case-checking tokeniser mode? |
| 11:50 | <hsivonen> | so yeah, using 'virtual' methods in Java would be acceptable when organized such that they compile away in C++ |
| 11:50 | <hsivonen> | Philip`: if on a boolean is slower than JITing away a no-op method on HotSpot |
| 11:51 | <Philip`> | If the boolean is constant then surely the whole if block would get JITted away |
| 11:51 | <hsivonen> | Philip`: if it's static final, then yes, I suppose |
| 11:52 | <hsivonen> | Philip`: I need a preprocessor mostrosity for splitting the tokenizer loop for .jar release anyway, though |
| 11:52 | <Philip`> | If you're toggling it ahead of compile time then it could easily be static final |
| 11:53 | <Philip`> | Might as well use the preprocessor monstrosity for as little as possible :-) |
| 11:54 | <hsivonen> | the reason why I haven't done a .jar release in a long time is that I lack the proprocessor monstrosity |
| 11:55 | <Philip`> | Is this because of the HotSpot maximum method size? |
| 11:55 | <hsivonen> | Philip`: yes |
| 11:55 | <Philip`> | Fun |
| 11:56 | <hsivonen> | Philip`: I can't really fix it in documentation for AppEngine and such |
| 11:56 | <hsivonen> | (actually, I have no clue if AppEngine runs a HotSpot derivative and has the same limitation) |
| 11:57 | <Philip`> | (I suppose it's better than C++ optimisers that have no maximum limits and happily use 2GB of memory on a single function and then crash after half an hour) |
| 11:57 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=501082 |
| 11:58 | <hsivonen> | the parser has so far hit compiler limitations in at least 4 compilers! |
| 11:58 | <hsivonen> | (MSVC, GCC, GWT and HotSpot) |
| 11:59 | <Philip`> | Is there a particular "and such" which you know has the same limit? |
| 11:59 | <Philip`> | If not, it seems like a (currently) purely hypothetical problem |
| 12:00 | <hsivonen> | Philip`: any environment where the person who opts to add a .jar doesn't have control over the JVM startup script for whatever bureaucratic reason |
| 12:00 | <hsivonen> | Philip`: for example, because .jars are chosen by a system supplier but JVM startup is performed by a customer |
| 12:00 | <hsivonen> | and the customer can't be botherede to read special instructions |
| 12:00 | <Philip`> | (Actually, I'm wrong even if everybody could control their JVM, since it would only be purely hypothetical if everybody read the documentation) |
| 12:01 | <Philip`> | (and I never read the parser documentation myself when I use it, other than the minimum necessary to make it compile and run) |
| 12:01 | hsivonen | goes back to implementing the new script data states |
| 12:26 | <gsnedders> | hsivonen: http://jsbeautifier.org/ is b0rked, I think new script data states fix this |
| 12:26 | <hsivonen> | gsnedders: known bug |
| 12:26 | <hsivonen> | (trying to fix it right now) |
| 13:21 | <hsivonen> | http://www.zeldman.com/2009/11/26/a-zing-too-far/#comment-50153 |
| 13:24 | <Dashiva> | Setting the record straight about misleading a generation of coders just because the w3c validator didn't support lint checking... |
| 13:26 | annevk2 | yawns |
| 13:26 | <Dashiva> | Every repost is repost repost, as they say elsewhere |
| 13:44 | <adactio> | Dashiva: Your use of the word "misleading" is misleading. It's also just plain wrong. |
| 14:06 | <Dashiva> | adactio: I'm sure you believe that, but just saying it won't make it so. |
| 14:22 | <adactio> | Dashiva: you are either misremembering or misunderstanding (not necessarily deliberately) but either way, what you claim is wrong. |
| 14:34 | <annevk> | Well, several people have certainly been "misled" in one way or another. Claiming that XHTML is faster, easier to parse, works better on mobiles, etc. |
| 14:34 | <annevk> | Gives you the ability to use namespaces, ... |
| 14:35 | <annevk> | It took me quite a while to realize how it really worked. |
| 14:36 | <jgraham> | Makes you more attractive to the opposite sex |
| 14:36 | <gsnedders> | 'Which country is smaller, China or Belgium?' --- what a terrible CAPTCHA |
| 14:37 | <TabAtkins> | Argh, my fingers keep tying "lolcalhost" |
| 14:37 | <annevk> | not lolcat? |
| 14:37 | <AryehGregor> | lolcathost |
| 14:38 | gsnedders | sighs... |
| 14:38 | <gsnedders> | I obvious can't type fast enough nowadays |
| 14:38 | <TabAtkins> | hehe |
| 14:39 | <annevk> | jgraham, I fail to see the joke :/ |
| 14:39 | <gsnedders> | annevk: XHTML is better in every way! |
| 14:41 | <jgraham> | annevk: I was thinking somewaht of http://www.jwz.org/doc/groupware.html |
| 14:46 | <jgraham> | (although now you've made me think about it really far too much I guess XHTML might actually have been good for that to some extent because it probably helped people get speaking gigs on the conference circuit allowing them to become markup rockstars with all the benefits that implies) |
| 14:46 | <jgraham> | (the moral of the story being: never let me think about offhand comments I make) |
| 14:47 | <TabAtkins> | Huh. The "wrap a div around the figure" trick appears to work. It makes IE7 forge a proper DOM. |
| 14:47 | <annevk> | aah, you want to be a markup rockstar jgraham? |
| 14:47 | <jgraham> | annevk: I'm good thanks :) |
| 14:48 | <TabAtkins> | It still styles things slightly funky if you apply the styles to <figure> directly (having made it a normal element through createElement()), but if you style the <div class=figure> instead, it all looks great. |
| 14:48 | <hsivonen> | TabAtkins: <div> is scoping |
| 14:48 | <TabAtkins> | I'll pretend I understand what that implies. |
| 14:50 | <TabAtkins> | (If someone could explain what that implies, it would be great.) |
| 14:50 | <AryehGregor> | Why should we? You understand, right? |
| 14:50 | <TabAtkins> | I'm just pretending to. |
| 14:50 | <AryehGregor> | Oh, okay then. |
| 14:51 | <AryehGregor> | We'd better not explain, or it will blow your cover. |
| 14:53 | <hsivonen> | certain searches in the tree builder stack terminate when encountering a scoping element |
| 14:54 | <AryehGregor> | Oh, well, that clears everything up, then. |
| 14:55 | TabAtkins | nods sagely, stroking his beard. |
| 14:55 | <AryehGregor> | Do you have a beard? |
| 15:06 | <TabAtkins> | AryehGregor: Yes. |
| 15:13 | <hsivonen> | woohoo! zcorpan's script escaping design fixed http://jsbeautifier.org/ |
| 15:13 | <hsivonen> | I'll head home, but try server builds should emerge at https://build.mozilla.org/tryserver-builds/hsivonen⊙if/ |
| 15:15 | <gsnedders> | hsivonen: Does validator.nu not have a textarea input any more? |
| 15:16 | <hsivonen> | gsnedders: it should... |
| 15:16 | <hsivonen> | gsnedders: it has for me |
| 15:17 | <gsnedders> | Hmm, in Minefield I see a dropdown beside the top field, in Opera I just see "document" |
| 15:18 | <gsnedders> | Oh, I have Javascript disabled. |
| 15:19 | <zcorpan> | hsivonen: nice |
| 15:19 | <hsivonen> | zcorpan: thank you |
| 15:20 | <zcorpan> | anytime |
| 15:23 | <gsnedders> | Even at 7am on Sunday morning? |
| 15:42 | <zcorpan> | jeremy's demonstration didn't use the createElement hack |
| 15:42 | <zcorpan> | but it appears to work fine with the hack too |
| 15:43 | <zcorpan> | unless ie8 compat mode is lying |
| 15:48 | <TabAtkins> | Who's in charge of the Selectors API? jgraham? |
| 15:49 | <annevk2> | it's at the top of the spec dude |
| 15:49 | <annevk2> | rtfs |
| 15:53 | <TabAtkins> | Bah, I had to actually google for that. Never mind that it took approximately as much time to do so as it took to ask the question, let alone wait for it to be answered. |
| 15:53 | <TabAtkins> | So! Anne! Isn't there already some plans to do some manner of namespace support in v2? |
| 15:56 | jgraham | wonders why he was the first guess |
| 15:56 | <jgraham> | Also why spotify is being so crappy |
| 15:58 | <TabAtkins> | jgraham: I dunno. My brain was telling me that I had argued with you about it in IRC. It's possible I was arguing with Lachy instead. |
| 16:01 | <gsnedders> | JohnResi1: Would it be possible to make test names constant in JQuery, or at least add some way to get constant test names? |
| 16:02 | <jgraham> | TabAtkins: I did discuss it on IRC at least once I guess |
| 18:09 | <Philip`> | With RDFa now planning to allow full URIs and CURIEs (and Safe CURIEs) in each attribute, I wonder how many users will forget to declare prefixes and then proceed to process their data using the prefixed forms |
| 18:09 | <Philip`> | i.e. generating a triple like <http://...> <cc:whatever> <http://...> (where "cc:whatever" is a full unabbreviated URI) and then happily processing the triples like that |
| 18:09 | <gratz|home> | CURIEs? |
| 18:10 | <Philip`> | You don't want to know :-) |
| 18:10 | <gratz|home> | oh no i do.. |
| 18:11 | <Philip`> | http://www.w3.org/TR/rdfa-syntax/#sec_3.8. |
| 18:11 | <Philip`> | but not http://www.w3.org/TR/curie/ because that's a bit different |
| 20:26 | <foolip> | Philip`: to be fair, aren't they just responding to the criticism brought forward? |
| 20:31 | <Philip`> | foolip: Yes, but that doesn't stop the outcome from seeming likely to cause confusion |
| 20:32 | <foolip> | time will tell :) |
| 20:33 | <foolip> | meanwhile I'm writing mail about microdata and enjoying it (don't understand my own fascination with metadata, but there it is) |