| 00:03 | <zcorpan_> | er, i thought TIME predated SMIL, no? |
| 00:03 | <Hixie> | HTML+TIME is a variant of SMIL for HTML. Not sure which came first. |
| 00:03 | <zcorpan_> | ok |
| 00:15 | <zcorpan_> | seems i've lost my password on blog.whatwg.org. i haven't received any email with my password, despite using the "lost your password?" thing twice |
| 00:15 | <Hixie> | weird |
| 00:17 | <zcorpan_> | ah, found it |
| 00:17 | <zcorpan_> | better change it to something i can remember |
| 00:28 | <zcorpan_> | blog post: "5 > 2. So now you know." should i say anything more? :) |
| 00:29 | <zcorpan_> | (title being the one om_beer suggested) |
| 00:29 | <zcorpan_> | (with "5 > 2" being a link) |
| 00:39 | <othermaciej> | zcorpan_: that's enough for people who know |
| 00:49 | <deltab> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html is empty and everything after it is missing |
| 00:50 | <Hixie> | yeah working on it |
| 00:50 | <Hixie> | the script is taking too much cpu on my box so i'm farming out the actual splitting to another box in the UK |
| 00:50 | <deltab> | why does it take too much cpu? |
| 00:51 | <zcorpan_> | http://blog.whatwg.org/t-shirts |
| 00:51 | <Hixie> | deltab: it's a big spec :-) |
| 00:52 | <deltab> | what's involved in splitting it? indexing and rewriting all the links, I guess |
| 00:53 | <Hixie> | http://html5.googlecode.com/svn/trunk/spec-splitter/spec-splitter.py |
| 00:53 | <Hixie> | it should be fixed now, btw |
| 00:56 | <Philip`> | deltab: It parses it into a DOM, then extracts the common header/etc bits, then it keeps moving bits from the original single page into the new output page, and it starts a new output page when it reaches certain points (mostly <h2>/<h3>), and when it's finished it goes through every page and finds every ID, then it goes through every page and updates the links, and then it serialises everything out to HTML, and that's about |
| 00:56 | <Philip`> | ... it. |
| 00:58 | <deltab> | ah, DOM + 1.5 MB source |
| 00:59 | <Philip`> | + Python :-) |
| 00:59 | <Hixie> | my update script now calls a web service on w3.org to create the big index page, then calls a web service on a server i have access to in the UK to split the spec up, and that web service calls a web service on whatwg.org to fetch the resulting tarball and unzip it, and then the original script goes ahead and does a svn diff. |
| 00:59 | <Hixie> | talk about a contraption. |
| 01:00 | <jdandrea> | Now THAT's quite a process. Hey, if it works, it works. |
| 01:01 | <Hixie> | it would be great parallel processing if it wasn't for the way that each script waits for the previous one to finish before doing anything |
| 01:03 | <Hixie> | by far the slowest part of this process now is the generation of the cross-references in the first place |
| 01:05 | <Lachy> | good morning |
| 01:05 | <Hixie> | might be time soon for me (or someone else) to write the script that takes the source file, and numbers the headers, generates the toc, and generates the cross-references |
| 01:05 | <Hixie> | hey lachy |
| 01:06 | <Philip``> | Hixie: I have a surprisingly similar (but totally unrelated) system - user commits to SVN on server A, A notifies server B, B updates SVN from A, B notifies C, C updates SVN from A, B spends ~20 minutes compiling the C++ application from SVN, C creates HTML/Atom of SVN history and SCPs it to server D, and after an hour B commits the compiled program back into SVN... |
| 01:07 | <Hixie> | hah |
| 01:07 | <Philip``> | The really surprising thing is that it actually works at all |
| 01:07 | <Hixie> | yeah |
| 01:07 | <deltab> | compiled programs in SVN? |
| 01:07 | <Philip``> | It's kind of grown over the years |
| 01:08 | <Philip``> | (Oh, I forgot that A also notifies Trac so it can automatically close tickets and email the relevant people) |
| 01:08 | <deltab> | oh, I suppose you don't want to spend time recompiling just to run an old version |
| 01:09 | <Philip``> | deltab: It's for a game where there are people (e.g. artists) who can't compile it themselves, so the best solution seems to be to put the executable file into SVN - they can just do a simple checkout and run it |
| 01:10 | <Hixie> | ok the multipage stuff now runs in the background so i no longer have to wait for that to finish to actually check in |
| 01:11 | <Hixie> | anyone know what the status of the annotate-data.xml file is? how to update it, etc? |
| 01:13 | <zcorpan_> | i haven't looked at it yet |
| 01:13 | <Hixie> | k |
| 01:13 | <Hixie> | i guess i should do an update to it, it's getting a bit stale |
| 01:14 | <zcorpan_> | i guess i should look at making it easier to update |
| 01:14 | <zcorpan_> | :) |
| 01:14 | <Hixie> | heh |
| 01:14 | <othermaciej> | I'm still snickering at Lachy's #xhtml log |
| 01:14 | <Hixie> | dude that was some disturbing stuff |
| 01:15 | <othermaciej> | at least they are safe in their padded cell (mostly) |
| 01:16 | <Hixie> | would be interesting to see shane speak to chris |
| 01:16 | <Hixie> | given shane wants to break content that isn't valid (over 93% of the web) and christ wants to not fix any bugs |
| 01:16 | <Hixie> | er, chris, not christ. |
| 01:17 | <othermaciej> | I'm not really sure what to say in response to Chris's stuff |
| 01:18 | <othermaciej> | but I'll have to write something |
| 01:18 | <Hixie> | you realise we're going to end up having to implement all these modes, right |
| 01:18 | <Hixie> | that's the most frightening part of this |
| 01:19 | <Hixie> | by "we" i mean mozilla/opera/apple in terms of browsers and me in terms of the spec |
| 01:20 | <othermaciej> | well, it depends on how quickly browsers fix other compat issues such that the modes are the most important compat isssue vs. changing balance of market share |
| 01:20 | <othermaciej> | it is somewhat true that due to browser targetting there are some bugs that are compat issues *only* for IE |
| 01:20 | <Hixie> | yeah the only way to get out of this mess would be for them to lose 50% market share, at which point they'd be even more screwed by their modes than we would |
| 01:21 | <othermaciej> | if we emulated some IE bugs in Safari, more content would break than stort working |
| 01:21 | <Hixie> | since we wouldn't have a mode, but they couldn't render the new stuff in their default mode |
| 01:21 | <Hixie> | which would be hilarious |
| 01:21 | <Hixie> | i really don't know what should happen, yeah |
| 01:21 | <Dashiva> | No hope of them committing to just fixing bugs before they become relied upon, I suppose |
| 01:22 | <Lachy> | I once thought that if FF, O and S implemented the spec and proved it was compat with the web, MS would follow, but it's now clear that sadly not the case |
| 01:22 | <Dashiva> | The reason people rely on e.g. peekaboo is because it wasn't fixed, not because they want to |
| 01:22 | <zcorpan_> | Lachy: indeed |
| 01:23 | <jdandrea> | I was just going to say that. "a bunch of people did expect that we didn't implement child selectors in CSS." No, speaking for myself, I _didn't_ expect it. It just became the norm for IE ... eventually. |
| 01:23 | <Hixie> | we're not going to convince microsoft not to do versionning |
| 01:23 | <Hixie> | we can definitely stand firm against spec-condoned opt-ins |
| 01:24 | <othermaciej> | well, there's one aspect of this that maybe cwilso hasn't thought about clearly |
| 01:24 | <Hixie> | and we can try to make the spec even more compatible than we have so far |
| 01:24 | Hixie | bites his tongue |
| 01:24 | <othermaciej> | which is that the likely content-breaking points of incompatibility are mostly in CSS and core DOM, not in HTML |
| 01:24 | <zcorpan_> | let's make the html4 strict and xhtml1 strict doctypes conforming html5 doctypes :) |
| 01:24 | <Hixie> | othermaciej: there's certainly some incompatibilities in html too, but yes |
| 01:24 | <othermaciej> | none of the examples he raised were actually HTML examples |
| 01:24 | <Hixie> | <button type=> default, parsing, those are html |
| 01:25 | <othermaciej> | (except for the <object> example which was fallacious) |
| 01:25 | <jdandrea> | othermaciej: Interesting point there ... ! |
| 01:25 | <Hixie> | yeah i don't know if he really believes his <object> argument or what |
| 01:25 | <Lachy> | zcorpan_, that may not be such a bad idea from an authoring tool perspective, since so many already insert such doctypes by default |
| 01:25 | <othermaciej> | amusingly, there is an Apple intranet site I know of that won't work in IE because of their differing button type default) |
| 01:26 | <Hixie> | hah |
| 01:26 | <zcorpan_> | i filed bugs about <button type> default and <button> using innerText instead of .value, but they were dismissed as "by design" |
| 01:26 | <Hixie> | ! |
| 01:27 | <zcorpan_> | i shit you not |
| 01:27 | <Dashiva> | "by design" means "by not being fixed long enough for sites to rely on it" :/ |
| 01:27 | <Lachy> | as I wrote in an off-list maill to Hixie last night, I think it would be good if <button> defaulted to type=button, but <button type=unknown> defaulted to type=submit |
| 01:28 | <othermaciej> | I wonder if it is true that MS got sued for fixing IE bugs |
| 01:28 | <zcorpan_> | <button> defaulting to type=button makes it harder to make repetition templates fallback server side |
| 01:28 | <Lachy> | ask him for evidence that it would happen |
| 01:28 | <zcorpan_> | you have to use client side script |
| 01:28 | <Hixie> | zcorpan_: well that's already hard |
| 01:28 | <Hixie> | zcorpan_: because of IE |
| 01:28 | <zcorpan_> | yes |
| 01:28 | <Hixie> | zcorpan_: the point is Lachy's suggestion doesn't break that |
| 01:28 | <jdandrea> | Didn't someone mention the EULA sort of limits their liability?? |
| 01:29 | <zcorpan_> | true |
| 01:29 | <Hixie> | zcorpan_: since those have <button type=unknown> |
| 01:29 | <Dashiva> | Even if the EULA says stuff, it can't override local law |
| 01:29 | <zcorpan_> | i would be fine with making <button> default to type=button then, given that ms don't intend to fix it |
| 01:30 | <Lachy> | he seems to be going from: Microsoft gets sued a lot to Microsoft will get sued for breathing |
| 01:30 | <Dashiva> | I would also enjoy default type button, since styling regular buttons is my main use for button |
| 01:30 | <Hixie> | zcorpan_: send a mail and i'll add it to the wf2 pile |
| 01:30 | <zcorpan_> | ok |
| 01:31 | <Hixie> | thanks |
| 01:31 | <Hixie> | ok i've reorganised the browsing contexts section to have a saner order, this should make it easier to write the spec |
| 01:31 | <Hixie> | and read it |
| 01:31 | <Dashiva> | So gentlemen, how do we get IE's market share down to 50% so they'll listen to reason? |
| 01:31 | <Hixie> | make ff3 suck less would be one start |
| 01:32 | <Dashiva> | That's replacing one impossibility with another |
| 01:32 | <othermaciej> | does FF3 suck? |
| 01:33 | <othermaciej> | as in, more than IE7? |
| 01:33 | <Hixie> | the ff3 trunk is bad |
| 01:33 | <Hixie> | crashy, slow, bloated, bigger download than ff2 |
| 01:33 | <Hixie> | not to mention flaky |
| 01:33 | <Hixie> | it's rather sad |
| 01:34 | <Lachy> | I had to uninstall teh FF trunk cause it kept crashing whenever I used it |
| 01:34 | <zcorpan_> | print preview in my fx trunk is broken |
| 01:35 | <Dashiva> | It's not like pre-beta builds are all that stable in general, of course |
| 01:35 | <Hixie> | this is worse than usual |
| 01:36 | <Hixie> | i've been using pre-alpha browsers for literally 9 or more years and this is the worst i've seen since the netscape 6 days |
| 01:37 | <zcorpan_> | what about .innerText vs .value on <button>? |
| 01:37 | <Hixie> | haven't done anything with .innerText yet |
| 01:37 | <Hixie> | what is it? |
| 01:37 | <Hixie> | i mean, what is it in the context of buttons |
| 01:38 | <Hixie> | i know what the attribute is in general |
| 01:38 | <zcorpan_> | ie submits .innerText to the server instead of .value |
| 01:38 | <zcorpan_> | <button type=submit value=pass>fail</button> |
| 01:38 | <Hixie> | ah |
| 01:38 | <Dashiva> | We can't spec that, it would make them even more useless than currently |
| 01:38 | <Hixie> | do other browsers do the right thing? |
| 01:38 | <Dashiva> | Might as well deprecate type=submit |
| 01:38 | <zcorpan_> | Hixie: yes |
| 01:39 | <Hixie> | let's leave it then, clearly it's not THAT important |
| 01:39 | <zcorpan_> | ok |
| 01:41 | <Dashiva> | If anyone ever made a page depending on that, I want to stab them :D |
| 01:41 | <Hixie> | they might not do it on purpose |
| 01:42 | <Dashiva> | It would require not specifying value at all, and still expecting one |
| 01:42 | <Hixie> | yeah |
| 01:42 | <Hixie> | easy mistake |
| 01:42 | <Hixie> | you know a lot of people write code by seeing what they get and coding to it |
| 01:42 | <Hixie> | not by thinking about what they're doing |
| 01:42 | <Hixie> | even you, i'm sure, do that |
| 01:42 | <zcorpan_> | logical way of working |
| 01:43 | <zcorpan_> | reading specs is more work |
| 01:43 | <Dashiva> | But the behavior when value in unspecified is unspecified, so other browsers could conform to that |
| 01:43 | <Dashiva> | Would be like <option> with no value |
| 01:44 | <zcorpan_> | yeah, that could work |
| 01:45 | <Dashiva> | Who wants to bring it up with MS? :) |
| 01:46 | <zcorpan_> | on public-html? |
| 01:46 | <Hixie> | just send a mail to the whatwg list and i'll update the spec in due course (make it explicit since i won't look at this for several months probably) |
| 01:46 | <Hixie> | btw if the multipage page gets out of sync let me know, the system is a bit brittle and i'm not sure why it's not always working |
| 01:47 | <zcorpan_> | Hixie: the mail i just sent, was it too brief? |
| 01:47 | <Hixie> | no that was fine |
| 01:47 | <Hixie> | cos it was a simple issue :-) |
| 01:47 | <zcorpan_> | ok |
| 01:47 | <Dashiva> | Should've mentioned defaulting to submit for unknown |
| 01:47 | <Hixie> | this issue is a bit more complex |
| 01:47 | zcorpan_ | drafts what we have discussed so far |
| 01:48 | <Dashiva> | "initial value of the button element is the value attribute, or the contents of the element if it is missing" |
| 01:52 | <Lachy> | Hixie, how widely used is <button type=submit>? |
| 01:52 | <Lachy> | do you have stats on that? |
| 01:53 | <Hixie> | looks like i don't |
| 01:53 | <Dashiva> | Anyone with Safari care to report the submitted values on http://folk.ntnu.no/magnusrk/test/buttonvalue.html ? |
| 01:53 | <Lachy> | I know I've used it, but none of my sites depend on IE's non-standard behaviour. They were all forced to work around it by not using a value |
| 01:53 | <Lachy> | 1. novalue= |
| 01:54 | <Lachy> | 2. emptyvalue= |
| 01:54 | <Lachy> | 3, value=non-empty+value |
| 01:54 | <Dashiva> | Same as FF and Opera then |
| 01:59 | <Dashiva> | Can anyone imagine a site specifying value but relying on innerText being submitted? |
| 02:00 | <Lachy> | it seems unlikely, <input type=submit> would be used far more often for that purpose |
| 02:00 | <zcorpan_> | well, some might use it as a way to identify ie on the server, for whatever reason |
| 02:01 | <Lachy> | but then if IE is was as standards compliant as other browsers, then it wouldn't really matter that much |
| 02:01 | <zcorpan_> | indeed |
| 02:01 | <Lachy> | unless the stupid site was using it to lock out other browsers |
| 02:01 | <Lachy> | but that seems unlikely to use that method |
| 02:02 | <zcorpan_> | from what i've heard the reason to process .innerText was to work around the bug. so fixing it wouldn't break those sites |
| 02:02 | <zcorpan_> | ...on the server that is |
| 02:02 | <zcorpan_> | or with js |
| 02:03 | <Dashiva> | It would only break if a site specifies value, but relies on only innerText, which only makes sense from a viewpoint of intentional breakage, not from laziness or ignorance |
| 02:03 | <zcorpan_> | Dashiva: what's the difference between the first and second button? |
| 02:03 | <Dashiva> | Empty attribute and missing attribute |
| 02:04 | zcorpan_ | doesn't see the empty attribute |
| 02:04 | <Dashiva> | ... right |
| 02:04 | Dashiva | fix |
| 02:05 | <Dashiva> | It doesn't really matter now, since it would only matter in browsers that implement the option-like behavior |
| 02:05 | <Hixie> | can someone rephrase this to fix the obvious problem without removing the precision and conformance criteria?: "When invoked as a constructor, this constructor must construct a" |
| 02:06 | <othermaciej> | the problem being word repetition? |
| 02:06 | <Dashiva> | How do you invoke a constructor as a non-constructor? Leaving out new? |
| 02:06 | <othermaciej> | many constructors can also be called as functions |
| 02:07 | <Hixie> | yes and yes |
| 02:07 | <Hixie> | i can replace the last "construct" with "replace a new" |
| 02:07 | <Hixie> | euh |
| 02:07 | <Hixie> | "return a new" |
| 02:07 | <othermaciej> | "return a new", yes |
| 02:08 | <Dashiva> | Could move the when clause to the end, but that would be easier to miss |
| 02:08 | <othermaciej> | and you could replace "this constructor" with the referent (which I assume is "the Audio constructor") |
| 02:08 | <Hixie> | Audio, Image, and Option at the moment |
| 02:08 | <Dashiva> | e.g. This constructor must return a new (...) when invoked as a constructor. |
| 02:09 | <Hixie> | the (...) is too long for that |
| 02:10 | <Dashiva> | "The constructor, when invoked as a constructor, must return a new" sounds silly |
| 02:10 | <Hixie> | ok i've used "When invoked as constructors, these must return a new" |
| 02:10 | <Hixie> | since they have multiple variants in each case |
| 02:13 | <othermaciej> | Hixie: if you really want to get technical, per the ES3 spec what happens during "new" is that the "[[Construct]]" internal property is called |
| 02:14 | <othermaciej> | but that's probably moredetail than you want and may be incompatible with future ES specs |
| 02:14 | <Hixie> | i'm also supposed to be pretending to attempt to stay language-neutral |
| 02:14 | <Hixie> | but yeah |
| 02:14 | <Hixie> | maybe i should just say that |
| 02:15 | <Dashiva> | Is whatwg involved in es4 in any way? |
| 02:15 | <zcorpan_> | *now* i got my password from the blog. very helpful :) |
| 02:15 | <Hixie> | i want a spec to define the whole HTMLFooElement and .prototype stuff too |
| 02:15 | <othermaciej> | other than vague overlap of participants, not really |
| 02:16 | <othermaciej> | Hixie: it would indeed be nice to have a spec for that, I wish it had existed before we reverse-engineered Firefox to add it to Safari |
| 02:16 | <othermaciej> | hmm, Chris Wilson's vacation mail says he will be at web 2.0 expo, I wonder if he'd be interested in meeting up for dinner or something |
| 02:17 | <Hixie> | you going to web 2.0 expo? |
| 02:18 | <othermaciej> | no, but it's in SF apparently |
| 02:19 | <Hixie> | ah |
| 02:19 | <Hixie> | well if he does want to meet up, let me know |
| 02:20 | <othermaciej> | roger that |
| 02:21 | <Hixie> | is this accurate?: |
| 02:21 | <Hixie> | Each Document has a scripting context, which provides a structure in which scripts can execute. Scripting contexts are associated with a domain, which defines the security context of that scripting context. Each scripting context also has a global scope, which is represented by the object representing the Document's default view, the Window object. |
| 02:21 | <othermaciej> | I'm not sure what "scripting context" means, but I think it is more properly associated with the browsing context than with the document |
| 02:22 | <Hixie> | oh right Window elements survive page loads |
| 02:25 | <Hixie> | so by the web's model, you couldn't make a browser that actively rendered and let you interact with more than one Document per browsing context, right? |
| 02:25 | <Hixie> | like, you couldn't have a live view of all the documents in history, one of them would have to be the "live" one |
| 02:27 | <Dashiva> | Hixie: How do iframes figure into that? |
| 02:28 | <Hixie> | oh, ignore those |
| 02:28 | <Hixie> | they introduce new browsing contexts |
| 02:29 | <Dashiva> | So browsing context and window are 1:1? |
| 02:29 | <Hixie> | yes |
| 02:30 | <Dashiva> | XMLHttpRequest lets you access a Document without a new window |
| 02:31 | <Dashiva> | Just creating empty Documents aside, I imagine there are other ways to instantiate new ones (LSParser, etc) |
| 02:31 | <Hixie> | the Document without a window isn't in a browsing context |
| 02:31 | <Hixie> | that's just a Document |
| 02:31 | <Hixie> | it can't be "live" |
| 02:33 | <Dashiva> | Well, if neither internal (above) nor external documents (frames) satisfy it, I don't see how it could happen |
| 02:33 | <Hixie> | imagine a UI where you can interact with all the documents in your session history at once |
| 02:33 | <Hixie> | instead of the current UI where you can only see one at a time |
| 02:34 | <Dashiva> | How would that be different from a tabbed browser with one static tab per page in history? |
| 02:34 | <Hixie> | with the tabbed ui, only one of the pages is "active" |
| 02:35 | <Hixie> | script isn't running in all of them at once, presumably |
| 02:35 | <Hixie> | or if it is, then it's what i'm describing, and my question is, does the model that html uses support that at all |
| 02:35 | <Dashiva> | Running a CPU-intensive script in one tab and focusing another should show scripts still run in all tabs |
| 02:36 | <Hixie> | current browsers don't let you put all the documents in your history in different tabs. |
| 02:37 | <Dashiva> | Caching details aside, could you not get the behavior by always using 'open in new tab'? |
| 02:38 | <Hixie> | no, because then they would be in different browsing contexts with different session histories. |
| 02:38 | <Hixie> | i'm talking about one session history |
| 02:38 | <Dashiva> | ah |
| 02:41 | <Dashiva> | In the JS circles I frequent, it's a truism that neither scripting context nor window survives a page load |
| 02:41 | <Hixie> | Window survives page load |
| 02:42 | <Hixie> | if you have an iframe and take its Window object, then navigate to another page in the iframe and take that Window object, and compare them, they're the same. |
| 02:42 | <Hixie> | with === equality |
| 02:42 | <Dashiva> | But a large amount of its properties are changed/reset |
| 02:42 | <Hixie> | same object though |
| 02:43 | <Dashiva> | Probably for implementation reasons, it doesn't offer any beneficial behavior that I can think of |
| 02:44 | <Dashiva> | To say, nothing would change if browsers started making new objects |
| 02:45 | <Hixie> | oh lots of sites would break |
| 02:45 | <Hixie> | lots of sites will grab the window object once and manipulate it across page loads |
| 02:45 | <Hixie> | (of a child iframe, e.g.) |
| 02:45 | <Hixie> | e.g. var x = window.open(...); /* time passes */ x.close(); |
| 02:46 | <Dashiva> | Ah, like that |
| 02:46 | <Hixie> | where while time passed, the window navigated to other pages |
| 02:47 | <Dashiva> | Yeah, that would break. A consequence of the mixing of window object and the frame/tab/window it's contained in |
| 02:48 | <Dashiva> | But Opera does manage to preserve the window properties of each page when going back and forward, somehow |
| 02:48 | <Hixie> | sure, all browsers do |
| 02:48 | <Hixie> | the html5 spec even says to do it |
| 02:48 | Dashiva | envisions time-share of the window object to allow concurrent use of a window object with different documents |
| 02:49 | <Dashiva> | But other than references to the window from other windows, is window object persistence otherwise used? |
| 02:50 | <Hixie> | not sure how else it could be used |
| 02:53 | <Dashiva> | Then I'll agree the current model doesn't allow concurrent live pages in the same session history, without some crazy time-sharing, but it could potentially be changed by making window references point to the containing frame/tab/etc and its current window object, rather than a specific one |
| 03:00 | zcorpan_ | updates notes at http://simon.html5.org/test/ie7b2-bugs/ |
| 03:05 | <zcorpan_> | perhaps the html parser should ignore </li> tags (like ie does) |
| 03:07 | <Hixie> | test case? |
| 03:07 | <Hixie> | i'm pretty sure i found it didn't ignore </li> |
| 03:12 | <zcorpan_> | http://simon.html5.org/temp/li.html |
| 03:12 | <Hixie> | interesting |
| 03:12 | <Hixie> | send mail |
| 03:12 | <Hixie> | i've gotta go |
| 03:13 | <Hixie> | thanks for the help |
| 03:13 | <zcorpan_> | ok |
| 03:13 | <zcorpan_> | np |
| 10:47 | <met_> | why html5 is not sgml? (just red http://annevankesteren.nl/2007/04/html-red-pill ) i am not sgml-fun, just thought almost any markup can be described by sgml, what is the difference |
| 10:48 | <zcorpan_> | sgml doesn't define error handling |
| 10:48 | <Lachy> | sgml isn't compatible with the web |
| 10:49 | <met_> | if you define what should happen for tag soup <x><y></x></y> it stops being sgml? |
| 10:50 | <zcorpan_> | Lachy: well, an application of sgml could be made compatible with the web (if we also define error handling), but assuming that the sgml declaration for html4 is in place then no. (and defining error handling for sgml is not appropriate for a higher-level spec to do) |
| 10:50 | <Lachy> | SGML rules would force <y> to close immediate before the </x> |
| 10:50 | <Lachy> | I don't think it's possible to write an SGML declaration that could handle all conforming documents |
| 10:51 | <zcorpan_> | and in any case, it's simpler to define the whole thing as a separate language than to continue to pretent that it is sgml |
| 10:51 | <Lachy> | you could get close, but not perfect |
| 10:51 | <zcorpan_> | ok |
| 10:51 | <met_> | thx |
| 10:51 | <zcorpan_> | and saying that it is sgml doesn't help implementors |
| 11:00 | <zcorpan_> | i should have an email filter that filters out all +1 and -1 emails |
| 11:01 | <hendry> | Maulkin: |
| 11:02 | <met_> | zcorpan_, just sum +1 and -1, this gives you zero and zero is not neccessary to read |
| 11:02 | <zcorpan_> | the problem is i can't figure out which emails are +1 and -1s until i read them |
| 11:02 | <zcorpan_> | and i don't want to read them |
| 11:03 | <zcorpan_> | they shouldn't enter my inbox |
| 11:03 | <zcorpan_> | obviously it would be nice if people just didn't send +1 or -1 emails |
| 11:04 | <met_> | they are used tom from digg and reddit this time |
| 11:04 | <met_> | just post mail to reddit and they can vote there 8-) |
| 11:04 | <zcorpan_> | i don't read digg or reddit |
| 12:37 | mpt_ | is amused that the XHTML2 WG inherited the venerable http://www.w3.org/MarkUp/ URL |
| 12:39 | <zcorpan> | should i add http://diveintomark.org/public/2005/12/whitelights/ to the html5 presentations page in the wiki? (it's about other stuff too) |
| 12:40 | <zcorpan> | (great presentation) |
| 12:40 | <krijnh> | Yes |
| 12:40 | <zcorpan> | (or slides, i didn't see the presentation) |
| 12:40 | <zcorpan> | ok |
| 12:41 | <mpt_> | it's an interesting presentation, but it mentions HTML5 only tangentially |
| 12:41 | <krijnh> | It's also from December 2005 |
| 12:41 | <zcorpan> | indeed |
| 12:41 | <krijnh> | Perhaps that's why it mentions HTML5 only tangentially |
| 12:41 | <krijnh> | (Learned a new word, yay) |
| 12:42 | <zcorpan> | perhaps he didn't want to talk about html5 exclusively |
| 12:42 | <mpt_> | It's mainly about writing |
| 12:42 | <zcorpan> | so should i add it or not? |
| 12:44 | <mpt_> | If this is a vote, mine's -1 |
| 12:44 | <krijnh> | Hmm |
| 12:44 | <krijnh> | What's the wiki URI? |
| 12:45 | <Lachy> | wiki.whatwg.org |
| 12:45 | <zcorpan> | mpt_: ok |
| 12:47 | <krijnh> | Ah, it only has 3 links, nah, then don't add it :) |
| 16:02 | <Lachy> | I started drafting up that blog entry to explain the situation - http://lachy.id.au/temp/mistakes |
| 20:29 | <gsnedders> | om_brunch: light blue would be nice (re: t-shirt colours) |
| 21:50 | <zcorpan> | othermaciej: http://blog.whatwg.org/t-shirts#comments |
| 21:52 | <othermaciej> | zcorpan: I'm not sure fantasai hating it is a bad thing (although she might be one of few potential customers for the girly version) |
| 21:53 | <othermaciej> | I think she missed the point that the obscurity is completely intentional |
| 21:53 | <othermaciej> | it's an inside joke, not an advocacy statement |
| 21:53 | <othermaciej> | as for doing it in a better font, that is probably being my personal skill level |
| 22:28 | <zcorpan> | just read through http://krijnhoetmer.nl/irc-logs/xhtml/20070413 . amusing. |
| 22:30 | othermaciej | cries |
| 22:35 | jdandrea | is reading ... "oh my ..." |
| 22:45 | <jdandrea> | "opera and apple ... are also-rans." ??? Ouch. |
| 22:46 | <zcorpan> | as if the "run" was over |
| 22:47 | <jdandrea> | exactly. |
| 22:47 | hsivonen | wonders how XHTML 2.0 fared :-) |
| 22:47 | <jdandrea> | Sounds like a cautionary tale to me. |
| 22:48 | <zcorpan> | sorry guys, ie won and firefox came second, no need to improve safari or opera anymore. let's pack our bags and go home. |
| 22:48 | <jdandrea> | heh |
| 22:52 | <jdandrea> | othermaciej: "oh my" the entire transcript @ http://krijnhoetmer.nl/irc-logs/xhtml/20070413 |
| 22:52 | <jdandrea> | Just finished it. Wow. Interesting times ... |
| 22:52 | <othermaciej> | oh, right |
| 22:52 | <othermaciej> | yeah |
| 22:53 | <othermaciej> | well, all Gecko-based browsers total used to have less market share than Safari does now |
| 22:53 | <othermaciej> | and Safari's is growing |
| 22:53 | <othermaciej> | anyway, that guy is a tool |
| 22:58 | <zcorpan> | interesting view though. "i don't care about the existing content on the web, if it stops working then who cares? it was invalid anyway. let's make up a new perfect language with no defined error handling, which isn't a problem because there will be tools that produce perfect code and UAs won't accept non-compliant code." |
| 22:59 | <zcorpan> | "and this is handled with a new doctype." |
| 22:59 | <zcorpan> | (that's how i interpreted it, anyway) |
| 23:00 | <jdandrea> | I'm a (relatively) late arrival to the WHAT-WG myself, but I've been reading the docs backwards and forwards and taking it all in. I like what I see! |
| 23:00 | <hsivonen> | what's the business interest of ApTest in XHTML 2.0? |
| 23:00 | <jdandrea> | I wonder what the ratio of real-world HTML-to-CSS concerns is for MS. Even a ballpark figure. |
| 23:01 | <othermaciej> | I think IE7 has made them scared to change anything ever |
| 23:01 | <jdandrea> | hmm |
| 23:01 | <jdandrea> | Someone warn Molly. |
| 23:02 | <othermaciej> | I wonder how she would feel about Chris's stance on versioning |
| 23:02 | <jdandrea> | Bingo. |
| 23:02 | <Dashiva> | Frustrated? |
| 23:03 | <zcorpan> | perhaps cwilso is afraid of losing his job |
| 23:05 | <zcorpan> | (just speculating) |
| 23:06 | <jdandrea> | Has anyone read his "Albatross!" blog posts? |
| 23:06 | <zcorpan> | pointer? |
| 23:06 | <jdandrea> | "I should be really clear here – I don’t really want to be the chair of the HTML Working Group." http://blogs.msdn.com/cwilso/archive/2007/01/10/you-me-and-the-w3c-aka-reinventing-html.aspx |
| 23:06 | <Dashiva> | zcorpan: He did say he thought he was close after IE7 |
| 23:06 | <jdandrea> | Though I may be quoting out of context. There's more to it ... |
| 23:07 | <zcorpan> | Dashiva: yeah, i meant that it might be the reason he wants versioning in ie |
| 23:07 | <othermaciej> | it's getting increasingly clear that he is not doing any actual chairing |
| 23:07 | <zcorpan> | jdandrea: yes i read it before |
| 23:07 | <jdandrea> | zcorpan: ahh, ok |
| 23:08 | jdandrea | answers the clarion call of din-din - bbl ... |
| 23:08 | <Dashiva> | He still hasn't explained how versioning is supposed to help when browser releases don't coincide with standard changes |
| 23:10 | <othermaciej> | if you think XHTML2 WG is crazy: http://news.yahoo.com/s/ap/20070413/ap_on_hi_te/rebuilding_the_internet |
| 23:11 | <zcorpan> | ha |
| 23:11 | <othermaciej> | forget replacing the web, how about replacing the whole internet? |
| 23:12 | <zcorpan> | why don't we move to another planet altogether? |
| 23:12 | <othermaciej> | a lot of Earth does not use proper semantic geography |
| 23:12 | <othermaciej> | so you have a good point there |
| 23:12 | <othermaciej> | we need a solar system that refuses to process planets which are not well-formed |
| 23:12 | <zcorpan> | i mean, the earth sucks, the only way to address security and mobility is to start from a clean slate |
| 23:13 | <zcorpan> | exactly |