| 00:10 | <caden> | do you ant to see it? |
| 00:10 | <caden> | s/ant/want/ |
| 00:15 | <shepazu> | Hixie: do elements in HTML5 have "default actions"? |
| 00:20 | <shepazu> | ok, I'll try again... anyone, do elements in HTML5 have "default actions"? |
| 00:20 | <shepazu> | or is that nonsense? |
| 00:23 | <annevk4> | shepazu, they have activation behavior |
| 00:24 | <annevk4> | shepazu, e.g. the activation behavior of <a> is to navigate |
| 00:25 | <shepazu> | annevk4: ok... so, is that the terminology of HTML5, HTML4, both...? |
| 00:26 | <shepazu> | and if link is activated, what events does it produce? |
| 00:26 | <annevk4> | activation behavior is associated with the click event |
| 00:26 | <shepazu> | does it produce a click, or only if it was activated by the mouse? |
| 00:26 | shepazu | writes a test |
| 00:26 | <annevk4> | always click |
| 00:27 | <annevk4> | anyway, the idea was for DOM3Events to define activation behavior and various related thingies, but bjoern never got around to it so now it's defined in HTML5 |
| 00:30 | <shepazu> | well, I'm actively editing DOM3 Events, so I'll define it there if it needs to be |
| 00:31 | <annevk4> | cool |
| 00:33 | <othermaciej> | shepazu: I think to support "click" and "DOMActivate" the way other browsers do, for elements that have an activation behavior, clicking needs to dispatch a "click" event whose default action is to dispatch a "DOMActivate" event, whose default action in turn is to perform the activation behavior of the element |
| 00:34 | <othermaciej> | shepazu: similarly, any activation not driven by the mouse (such as via keyboard or by calling the click() method) needs to dispatch a synthetic "click" event same as above |
| 00:34 | <othermaciej> | shepazu: if DOM3EV defines all this, then HTML5 could limit itself to stating which elements have activation behavior, and what that behavior is for each one |
| 00:34 | <othermaciej> | (I think) |
| 00:35 | <annevk4> | yeah, that is pretty much how HTML5 does it |
| 00:35 | <annevk4> | I still think we should nuke DOMActivate though |
| 00:36 | <shepazu> | what would change your mind? |
| 00:37 | <othermaciej> | DOMActivate adds code complexity, and it's not clear if it serves a useful purpose |
| 00:37 | <othermaciej> | otoh now that we've implemented it, it's not a huge burden to maintain support |
| 00:37 | <shepazu> | othermaciej: do you think it would be useful for D3E to define it? I guess if it did, I reckon I'd more or less take whatever HTML5 says on it |
| 00:38 | <shepazu> | it would be useful for e.g. SVG, I think |
| 00:38 | <annevk4> | shepazu, a good reason for having it besides click? |
| 00:39 | <othermaciej> | shepazu: I think it makes sense to define the notion of activation in D3E, because I think all specs with activation behavior would want to do it the same |
| 00:40 | <shepazu> | ok, I'll put that in an upcoming draft, thanks |
| 00:40 | <othermaciej> | annevk4: does Opera support DOMActivate? |
| 00:41 | <annevk4> | seems like we don't |
| 00:42 | <annevk4> | I filed the original bug for it in 2005 or so and all duplicates were from third-party testers |
| 00:42 | <othermaciej> | I'm wondering how likely it is that any Web content depends on it |
| 00:42 | <annevk4> | given the details I have it seems highly unlikely |
| 00:43 | <annevk4> | apart from some tests here and there |
| 00:43 | <shepazu> | could we find out from MAMA? |
| 00:43 | <shepazu> | or from Google's research? |
| 00:44 | <annevk4> | we can never be really sure, but both Opera and IE not supporting it seems like a good indicator to me |
| 00:46 | <othermaciej> | despite what Chaals said, I don't see WCAG specifically requiring DOMActivate |
| 00:47 | <othermaciej> | annevk4: it's possible sites could be using it in non-IE code paths and not caring or knowing that they break in Opera, although there doesn't seem much reason to doing it |
| 00:47 | <Darxus> | The head element says it contains "One or more elements of metadata content, of which exactly one is a title element." |
| 00:48 | <annevk4> | othermaciej, I guess |
| 00:48 | <annevk4> | othermaciej, I'd be interested in that code :) |
| 00:48 | <othermaciej> | Is there any SVG content that depends on DOMActivate? |
| 00:48 | <Darxus> | The meta element says it can be contained in the head element. Nowhere does it says anything about number of times. This annoys me. Although I suppose that means >=0. |
| 00:48 | <othermaciej> | (whether Web-published or not?) |
| 00:49 | <othermaciej> | So far it seems like the only hard dependency is XForms, and that doesn't seem like a good enough reason by itself |
| 00:50 | <othermaciej> | SVG 1.2 Tiny seems really vague about what elements will trigger a DOMActivate or what causes this to happen |
| 00:50 | <Darxus> | It'd be fun for gnuplot to have a terminal type of html5canvas. |
| 00:51 | <Darxus> | Actually, has anybody written a SVG / postscript / etc. converter to <canvas> yet? |
| 00:51 | <othermaciej> | it's implied that any rendered element can have activation behavior, the example given is a <circle> |
| 00:51 | <othermaciej> | Dino wrote a basic SVG-to-<canvas> converter long ago |
| 00:52 | <shepazu> | sorry, othermaciej, I was chopping mushrooms |
| 00:54 | <shepazu> | othermaciej: I don't know if any SVG content depends on it... I'm at a loss to find out if it does, other than surveys like MAMA |
| 00:55 | <annevk4> | figuring out if stuff breaks in experimental impl is likely a good solution |
| 00:55 | <annevk4> | again though, also for SVG we have received no bug reports on DOMActivate (apart from a test) |
| 00:57 | <shepazu> | othermaciej: well, if a circle had a DOMActivate event listener, or maybe a SMIL child element element... but other than that, I don't think any element in SVG should have default "activation behavior" than <a> |
| 00:57 | shepazu | tries to think of what other elements there might be in SVG that have activation behavior... |
| 00:59 | <shepazu> | http://www.w3.org/TR/SVGTiny12/elementTable.html |
| 00:59 | <shepazu> | maybe <audio> and <video>... |
| 00:59 | <annevk4> | elements are activatable based on their event listeners in SVG? ouch |
| 01:00 | <annevk4> | oh well, I suppose it does not matter much |
| 01:02 | <shepazu> | annevk4: how is it controversial to make an element activateable by putting a "DOMActivate" listener on it? I'm confused... |
| 01:03 | <shepazu> | but would the activation behavior of a multimedia element vary on whether the content was already playing or not? what's the activation behavior of HTML multimedia elements? |
| 01:03 | <annevk4> | shepazu, it seems activation behavior should come from semantics |
| 01:04 | <othermaciej> | shepazu: making an element activatable by putting a "DOMActivate" listener on it would be somewhat weird - an ancestor element with a DOMActivate listener would see the inner element get DOMActivate if and only if the inner element had its own listener |
| 01:05 | <shepazu> | othermaciej: ok |
| 01:06 | <othermaciej> | shepazu: since DOMActivate bubbles, that would be somewhat illogical I think |
| 01:06 | <othermaciej> | also, in general, listeners observe events, but don't observably affect what events get dispatched just by their presence |
| 01:06 | <shepazu> | I'm just grasping at straws on what elements in SVG would have inherent activation behavior... links, multimedia elements, maybe SMIL elements that didn't have explicit @begin values? |
| 01:07 | <annevk4> | seems like www-svg might be a better place to ask that than #whatwg :) |
| 01:07 | <othermaciej> | you could make the case that every SVG element should be activatable, but it's kind of unclear what forms of non-click activation, if any, would work for something like <circle> or <path> |
| 01:07 | <othermaciej> | and what the activation behavior would be |
| 01:07 | <Darxus> | I just had an HTML5 comprehension breakthrough. The "meta" element is in the "encoding declaration state" when its "http-equiv" attribute has a value of "content-type". |
| 01:08 | <othermaciej> | I could buy the argument that an activation-triggered SMIL animation makes you activatable, although that's a complicated rule |
| 01:08 | <othermaciej> | I think SVG <a> elements are clearly activatable |
| 01:08 | <shepazu> | yes, <a> is understood |
| 01:09 | <shepazu> | it's not actually a concept that SVG has had to deal with much, since there are so few truly activateable elements, I guess |
| 01:10 | <shepazu> | whereas HTML has quite a few |
| 01:10 | <Darxus> | Contexts in which the "meta" element can be used really should be changed from "If the charset attribute is present, or if the element is in the Encoding declaration state: in a head element." to 'If the charset attribute is present, or if the attribute "http-equiv" is set to "content-type".' |
| 01:11 | <shepazu> | annevk4: are you seriously telling me that I shouldn't try to resolve open questions about improving SVG by asking opinions in #whatwg |
| 01:12 | <annevk4> | I thought this was a question about how SVG works today |
| 01:12 | <annevk4> | because of "would" |
| 01:12 | <othermaciej> | annevk4: I think it's more a question of how it should work per spec, if D3E centrally defines the concept of activation |
| 01:13 | <othermaciej> | but it would also be useful to determine when actual SVG implementations fire DOMActivate events, and if this seems logical |
| 01:13 | shepazu | looks closer at activation behavior in HTML5, including where it's used |
| 01:13 | <annevk4> | shepazu, also, I included a smiley... |
| 01:16 | <othermaciej> | HTML5 actually defines that any element that is forced to be keyboard focusable by tabIndex is activatable |
| 01:16 | <othermaciej> | (with an activation behavior that does nothing, unless it would otherwise have an activation behavior) |
| 01:16 | <shepazu> | yeah, just looking at that |
| 01:16 | <shepazu> | ah, ok, thanks, that clarifies it |
| 01:17 | <othermaciej> | and <a>, <label>, <input>, <area>, <command> and <button> may have some built-in activation behavior, depending on circumstances |
| 01:18 | <othermaciej> | oddly, <bb> does not have defined activation behavior |
| 01:18 | <shepazu> | in that case, most SVG elements would have similar behavior for those elements, but still no true activation behavior... maybe it would be more accurate to say that the focusable attribute adds activation behavior |
| 01:19 | <shepazu> | othermaciej: maybe an oversight? |
| 01:19 | <othermaciej> | dunno - I'll send a comment |
| 01:20 | <shepazu> | I don't know the <bb> elements... you know of an example that uses it? the spec seems vague |
| 01:22 | <othermaciej> | it's not implemented or used by anyone yet |
| 01:22 | <Darxus> | Suggested changes to the draft go to the implementors list? |
| 01:22 | <othermaciej> | it's just... buttonish |
| 01:23 | <annevk4> | Darxus, no, to whatwg⊙wo |
| 01:23 | <annevk4> | I'm not really sure <bb> makes a lot of sense and the name is confusing |
| 01:23 | <Darxus> | annevk4: Just figured that out, thanks. |
| 01:24 | <othermaciej> | it's foolish to use such a heavily abbreviated name for an element with such a (relatively) obscure purpose |
| 01:25 | <annevk4> | I suggested (on behalf of someone else) <browserbutton> |
| 02:22 | <tantekc> | annevk4 - I just took a look at http://dev.w3.org/html5/markup/bb.html - and assuming that is close to what the <bb> tag currently means in HTML5, I strongly recommend NOT calling that a <browserbutton> |
| 02:23 | <tantekc> | the term "browser button" is already fairly widely used (Google, Technorati, others) as a less jargony replacement for what is otherwise known as a "bookmarklet" or "favelet" |
| 02:23 | <tantekc> | http://www.google.com/options/buttons.html |
| 02:23 | <tantekc> | http://technorati.com/tools/favelets.html |
| 02:36 | <csarven> | <bb> sounds pretty close to <input type="button"> http://www.w3.org/TR/html401/interact/forms.html#push-button |
| 02:37 | <csarven> | At least my understanding of it |
| 02:57 | <tantek> | csarven - in that case, if it's not clear how it's substantially different from <input type="button"> I would be for dropping the feature from the spec. |
| 02:59 | <tantek> | (dropping <bb> that is) |
| 02:59 | <csarven> | :) |
| 03:06 | <csarven> | http://dev.w3.org/html5/markup/input.button.html#input.button still exists, so, probably best that <bb>'s definition is cleared up, otherwise dropped if it had the same intention as <input type="button"> |
| 03:08 | <csarven> | Is there a backlog sort of a document for what (and why) makes it into draft? Not particularly in the mood to track this down in the mailing list =) |
| 03:10 | <tantek> | csarven - I don't think I'm ever in the mood to track something down in a mailing list. |
| 03:12 | <csarven> | I don't know how Hixie manages his emails. That requires mad skills and sanity. |
| 03:41 | <othermaciej> | <bb> is supposed to be a special button for built-in UA functionality that it's generally believed should be restricted to user actions |
| 03:41 | <othermaciej> | so it's somewhat different than <input type="button"> - may have a custom rendering and its behavior is likely different than a normal button |
| 03:41 | <othermaciej> | but I think an element for that particular slice of functionality is overkill |
| 03:46 | <tantekc> | othermaciej - is there a wiki page where we can vote down elements? |
| 03:47 | <othermaciej> | tantekc: I don't believe there is |
| 03:47 | <othermaciej> | I think the official way to register your displeasure would be by sending mail to the list |
| 03:51 | <tantekc> | I think I'd prefer to unofficially collect more data before making an official statement |
| 04:06 | MikeSmith | makes not to remember to tell tantek that another mechanism is to raise an issue at http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG |
| 04:54 | <Darxus> | Body elements are a lot easier to define than those in the header. I initially assumed the header would be much easier. |
| 05:07 | <Darxus> | Er, the page ended. The list of elements didn't. |
| 05:07 | <Darxus> | I am thankful for recursion. |
| 07:32 | <MikeSmith> | Hixie: I have a big favor to ask |
| 07:45 | <Philip`> | MikeSmith: http://dev.w3.org/html5/spec/404.html has wrong charset |
| 07:47 | <Philip`> | (Also, multipage pages don't seem to run the broken-link-fixing script, so if e.g. a block moves from one page to another then links to it won't work) |
| 07:55 | <MikeSmith> | Philip`: I (re)disabled the broken-link-fixing script temporarily |
| 07:56 | <MikeSmith> | because, genius that I am, the makefile change I added that enabled it also had the effect of generating a sort of endless cvs commit loop |
| 07:56 | <MikeSmith> | which by the time I stopped it had robotically committed about 80 updates to the draft |
| 07:57 | <MikeSmith> | to do it proper, I will need for Hixie to add <body onload="fixBrokenLink()"> to his W3C Overview.html file |
| 07:59 | <Philip`> | Oh, sounds excellent |
| 07:59 | <Philip`> | It's lucky you were using CVS, rather than a fast modern VCS that would have done millions of commits |
| 08:00 | <MikeSmith> | yeah |
| 08:01 | <MikeSmith> | thank god for the inefficiency of cvs |
| 08:07 | <MikeSmith> | Philip`: OK, I set UTF-8 as the default charset for the directory |
| 09:25 | <Philip`> | Hmm, a few days ago I attempted to use lang="" properly, for about the first time ever |
| 09:26 | <Philip`> | and now I discover that although my first use was correct, my second use was an accidentally copied <html lang="tr"> onto an English page |
| 09:26 | Philip` | apologises for polluting the world of metadata |
| 09:30 | <Lachy> | Philip`, nevermind, at least you have found and corrected your mistake, and order has been restored to the web. |
| 09:33 | <MikeSmith> | "the Web is an unkind mistress" |
| 09:34 | <Philip`> | I also completely forgot to add alt text to some images that really should have them (some plain icons, some icons in links) and the validator didn't remind me at all |
| 10:13 | <takkaria> | MikeSmith: it's the XML people who want to make it an unkind mistress, right now it doesn't really bother with the mistressing part AFAICT |
| 10:15 | <MikeSmith> | it's a fickle mistress, then |
| 10:18 | <takkaria> | I can live with that |
| 10:33 | Philip` | thinks something is really broken in his monitor, before realising Opera 10 now has a funky background image on error pages |
| 10:48 | <Rik|work> | arg, http://hsivonen.iki.fi/ is down :( |
| 11:36 | <takkaria> | hmm |
| 11:36 | <takkaria> | HTTP headers with q values were a really stupid idea |
| 11:37 | <takkaria> | should just have put things in a comma-separated list in order of preference |
| 11:38 | <Philip`> | Is the idea of "preference" not really stupid? |
| 11:39 | <Philip`> | I can't imagine how a browser developer would decide whether they prefer JPEG or PNG, or whether they prefer HTML or XHTML, etc |
| 11:39 | <Philip`> | since it depends on the content, and that depends on the server and the author and not on the browser |
| 11:39 | <takkaria> | I was thinking about Accept-Language myself |
| 11:40 | <Philip`> | Oh, okay |
| 11:40 | <takkaria> | but yeah, asking them to prefer one format over the other is a bit bizarre |
| 11:40 | <Philip`> | In that case it makes more sense, because users are likely to have preferences, and they use their browser to convey those preferences to the server |
| 11:41 | <Philip`> | (for languages) |
| 11:41 | <takkaria> | yeah, but the q-value bit is still nutty |
| 11:41 | <annevk4> | on top of that content negotiation does not really work |
| 11:49 | <gsnedders|work> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/185 really does seem suboptimal in WebKit |
| 12:06 | <olliej> | gsnedders|work: in the nightly? |
| 12:08 | <gsnedders|work> | olliej: In Chromium linux nightly at least |
| 12:08 | <olliej> | gsnedders|work: meh |
| 12:09 | <gsnedders|work> | olliej: I can't test Safari here :P |
| 12:09 | <olliej> | gsnedders|work: poor excuse |
| 12:09 | <olliej> | gsnedders|work: there's epiphany-webkit :P |
| 12:09 | <gsnedders|work> | olliej: But that's not in Ubuntu's repos :P |
| 12:09 | <olliej> | gsnedders|work: which uses real webkit :D |
| 12:09 | <olliej> | gsnedders|work: :p |
| 12:10 | <gsnedders|work> | olliej: Yeah, I know. I'm just trying to think of what does use WebKit+JSC and is in the repos :P |
| 12:18 | <zcorpan> | hsivonen: http://simon.html5.org/test/html/parsing/innerhtml.html hangs with the html5 parser |
| 12:21 | <annevk4> | zcorpan, your progress bar is tag abuse |
| 12:21 | <MikeSmith> | gsnedders|work: you can test WebKit nightlies on Linux using Arora |
| 12:21 | <gsnedders|work> | annevk4: It's not zcorpan'S test |
| 12:22 | <MikeSmith> | gsnedders|work: Qt-based .. it's pretty easy to build |
| 12:22 | <gsnedders|work> | MikeSmith: But that means I can't just reply upon package management to update it ever day ;P |
| 12:23 | <MikeSmith> | gsnedders|work: you update it by running "make" and "make install", as God intended |
| 12:25 | <gsnedders|work> | MikeSmith: I guess I could use a cron to update it |
| 12:27 | <MikeSmith> | gsnedders|work: http://code.google.com/p/arora/wiki/source#Building_with_Trunk |
| 12:46 | <Philip`> | gsnedders|work: You could switch to Gentoo, and then use www-client/arora |
| 13:11 | <zcorpan> | has anyone pointed out that DOMFocusIn bubbles while focus doesn't? |
| 13:12 | <othermaciej> | zcorpan: I believe it has been mentioned several times |
| 13:12 | <othermaciej> | I don't think that makes for a usefully distinct use case |
| 13:13 | <annevk4> | there's hardly any use case attached to that though, unless you have event handlers |
| 13:13 | <othermaciej> | non-bubbling is the sensible behavior for foucs |
| 13:14 | <othermaciej> | unlike clicks or mouse moves, a child of element X being focused should generally *not* be treated the same as if element X was focused |
| 13:15 | <othermaciej> | (and yes, nested focus is possible and may not even be entirely useless) |
| 13:15 | <othermaciej> | (consider an area that you can keyboard scroll when it has focus, but which contains form controls which can themselves have focus) |
| 13:15 | <annevk4> | (or the <video> element) |
| 13:16 | <othermaciej> | I think the only plausible argument for DOMFocusIn is if content indeed depends on it |
| 13:16 | <othermaciej> | and I think there's no argument whatsoever for standardizing focusin/focusout |
| 13:17 | <annevk4> | yeah |
| 13:17 | <annevk4> | I'm guessing I'm not going to be happy with the solution; similarly namespace support is still included despite nobody really asking for it |
| 13:24 | <gsnedders|work> | Philip`: Ubuntu has Arora packages, just not with WebKit trunk |
| 13:36 | <gsnedders|work> | Is there anything apart from @import that takes a URL but not as <uri> in CSS |
| 13:37 | <gsnedders|work> | ? |
| 13:40 | <othermaciej> | annevk4: I thought we dropped namespaced event support long ago |
| 13:40 | <othermaciej> | annevk4: is it really still in there? |
| 13:41 | <othermaciej> | I wish the D3E editor's draft was easily googlable |
| 13:43 | <annevk4> | it is still there http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html |
| 13:44 | <annevk4> | and for some reason the editor seems to assume my comments are in bad faith :/ |
| 13:44 | <annevk4> | wtf |
| 13:50 | <zcorpan> | annevk4: do we support the namespaced stuff in opera? |
| 13:51 | <annevk4> | jl made an experimental impl once, I don't think it ever landed |
| 13:51 | <annevk4> | you'd have to check with bratell to be sure though |
| 14:54 | <gsnedders|work> | http://html5.digitalbazaar.com/a-new-way-forward/ |
| 14:56 | <takkaria> | uh? |
| 14:56 | <takkaria> | "The single greatest complaint heard from the standards community concerning the development of HTML5 is that it has not allowed for the scientific process. |
| 14:58 | annevk4 | wonders what "If your company depends on the Internet and can afford to fund just a small fraction of the work above (minimum $8K grant), then please contact him at msporny⊙dc" is about |
| 15:06 | <takkaria> | Manu seems to have missed the point as to why people in the whatwg list can't join the HTMLWG list |
| 15:06 | <takkaria> | *not all people |
| 15:07 | <takkaria> | and the idea that merging mailing lists will suddenly make people happy is a bizarre one |
| 15:10 | <takkaria> | and again with the "HTML5 has no distributed extensibility" meme |
| 15:10 | <takkaria> | sheesh |
| 15:13 | gsnedders|work | reminds himself that replying to that is not a productive use of his time |
| 15:14 | <takkaria> | a fair bit of that makes some interesting proposals |
| 15:14 | <gsnedders|work> | Mostly ones that have been made before, though |
| 15:14 | <takkaria> | but things like "Better, more precise accessibility language for HTML5." do kind of make me want to scream |
| 15:15 | <takkaria> | and saying that the scientific process is being disregarded whilst also saying experts don't get to dictate what happend next |
| 15:15 | <takkaria> | but yeah, responding to this isn't a good use of time |
| 15:16 | takkaria | goes back to work |
| 15:18 | <gsnedders|work> | I'll reply to it later, probably |
| 15:18 | gsnedders|work | creates a lynx -dump copy of that file to reply to |
| 15:22 | <Lachy> | "HTML5 is currently a walled garden that must be opened to the greater standards community in order to ensure a stable framework for the future of the Web." -- http://html5.digitalbazaar.com/a-new-way-forward/ |
| 15:23 | <Lachy> | It's ironic that HTML5 has the most open development process compared with any previous HTML spec. |
| 15:23 | <takkaria> | no, see, 1000 people on a mailing list isn't open enough |
| 15:23 | <takkaria> | we need to open it to the experts. :) |
| 15:27 | <Lachy> | "In a CTC process, as used at the W3C, consensus should be reached before an editor changes a document." - we would never get anything done with that process |
| 15:28 | <Lachy> | we'd get more criticism from people complaining about how the spec has stalled if we adopted a process like that |
| 15:29 | <takkaria> | he doesn't suggest we move to a CTC model |
| 15:30 | <takkaria> | just that we magic up more committers |
| 15:30 | <gsnedders|work> | Lachy: Well, we can't publish until we have consensus, and I think in terms of time taken there's no difference between getting consensus on changes first and getting consensus after |
| 15:35 | <annevk4> | the HTML5 editor model is not that weird actually |
| 15:35 | <annevk4> | the CSS WG and WebApps WG are also using it |
| 15:35 | <annevk4> | those groups do make group decisions a bit more often than the HTML WG |
| 15:35 | <Lachy> | "it is difficult to tell which parts of the specification are at which level of maturity without deep knowledge of the history of the document" - Now he's just blatently ignoring the status markers we've had for over a year |
| 15:36 | <annevk4> | he might be reading the W3C edition |
| 15:36 | <Lachy> | annevk4, those groups are also smaller and don't have such large and diverse communities forming around them |
| 15:37 | <annevk4> | I'm not sure I'd say that about CSS, but the community there has arguably less of a say |
| 15:38 | gsnedders|work | wonders why HTML 5 and CSS 3 doesn't |
| 15:47 | <Lachy> | "The issue is that there are currently no proposals for distributed extensibility in HTML5 " - now that's just a blatant lie. He knows full well that the microdata section is in the spec for that. He may not like it as it is, but lying about it not being there doesn't help |
| 15:49 | <MikeSmith> | annevk4: I guess we should try to get the annotations added to the W3C version also |
| 15:52 | <Darxus> | It confused me for a few days that the status markers shown in the demo video weren't in the W3C version, because I wasn't looking at the WHATWG version. |
| 16:00 | <zcorpan> | demo video? |
| 17:16 | <vs-hs> | whatwg? |
| 17:16 | <vs-hs> | thelinx: :D |
| 17:17 | <Lachy> | vs-hs, what? |
| 17:17 | <vs-hs> | Lachy: No idea |
| 17:47 | <Darxus> | The spec has not been written primarilfy for validator implimentors. |
| 17:49 | <gsnedders|work> | The spec hasn't been written primarily for anyone |
| 17:51 | <Darxus> | The "Contexts in which this element may be used" and "Content model" have very different wording cosidering that they directly correspond to each other. |
| 17:52 | <Darxus> | Maybe change "Contexts in which this element may be used" to "Content models in which this element may be used" |
| 17:54 | <Darxus> | I should just write a parser that converts http://www.whatwg.org/specs/web-apps/current-work/ to schema :P |
| 18:01 | <Darxus> | <define name="phrasing_content"></define name="phrasing_content"> is invalid xml? :( |
| 18:01 | <Philip`> | Only start tags have attributes |
| 18:02 | <gsnedders|work> | Darxus: It's invalid in SGML and HTML too. |
| 18:03 | <Darxus> | Lame. |
| 18:03 | <Darxus> | I just prefer it over |
| 18:03 | <Darxus> | <define name="phrasing_conent"> |
| 18:04 | <Darxus> | </define> <!-- end of phrasing_conent --> |
| 18:04 | <takkaria> | most people use indentation. :) |
| 18:04 | <Darxus> | Yeah, but this is for a case where the <define> is several pages long, so I'm not really sure which one I'm adding to without something like the above. |
| 18:05 | <Darxus> | Well, phrasing_contenet isn't that big, but flow_content is. |
| 18:05 | <Philip`> | <phrasing_content>...</phrasing_content> |
| 18:05 | <Darxus> | Philip`: I'd rather more closely follow relax ng. |
| 18:06 | <gsnedders|work> | Darxus: Why not use RelaxNG? |
| 18:06 | <Darxus> | Is xml 1.0 sgml conformant? To make </define name=""> valid xml, would I need to also update the sgml standard? |
| 18:06 | <gsnedders|work> | Darxus: And why not http://syntax.whattf.org/? |
| 18:06 | <Darxus> | gsnedders|work: Because it is not capable of specifying HTML5 to the HTML5 validator conformance requirements. |
| 18:06 | <gsnedders|work> | Darxus: XML 1.0 is a subset of SGML. |
| 18:07 | <Darxus> | gsnedders|work: That sounds like a yes. |
| 18:07 | <gsnedders|work> | Darxus: Sure, but do we need another schema language? |
| 18:07 | <Darxus> | gsnedders|work: If there isn't one that can sufficiently specify HTML5, I think so. |
| 18:07 | <gsnedders|work> | Darxus: Is RelaxNG with Schematron not enough? |
| 18:07 | <Darxus> | gsnedders|work: Yes. |
| 18:07 | <gsnedders|work> | Darxus: In what way? |
| 18:08 | <Darxus> | gsnedders|work: While Henry's thesis index is loading... one example was validating the layout of a table element. |
| 18:09 | <Darxus> | HTML5 requires that a table have, for example, no cells overlapping. No existing schema language can specify that. Henry implimented the requriement in java. |
| 18:09 | <gsnedders|work> | *Henri |
| 18:09 | <gsnedders|work> | Schematron should be able to check that though, I think. hsivonen's point is that you can't do it in any schema language, but Schematron isn't; a schema language. |
| 18:10 | <Philip`> | s/;// |
| 18:10 | gsnedders|work | doesn't entirely like this keyboard |
| 18:11 | <Darxus> | gsnedders|work: So why, when he was using both relax ng, and schematron, did he impliment some rules in java? |
| 18:11 | <gsnedders|work> | Darxus: Performance. |
| 18:11 | <Darxus> | And... schematron isn't a schema language? |
| 18:12 | <gsnedders|work> | I wouldn't call rule-based validation a schema |
| 18:12 | <gsnedders|work> | But yes, I guess technically it is |
| 18:13 | <gsnedders|work> | Ah, some of the data types can't be expressed in Relax NG apparently |
| 18:13 | <Darxus> | I believe schematron is not capable of sufficiently specifying HTML5. If I am incorrect, I would love to know. |
| 18:15 | <takkaria> | Darxus: you're inventing a schema language so you can write a validator that takes that schema language and uses it? |
| 18:15 | <gsnedders|work> | According to the intro of hsivonen's thesis, it is possible to check everything apart from some data types using RelaxNG+Schematron |
| 18:15 | <Darxus> | Schematron.com's header totally needs to be an svg. |
| 18:15 | <Darxus> | takkaria: That's my plan. |
| 18:16 | <Darxus> | I make no claims at being qualified to impliment this plan, but it entertains me. |
| 18:16 | <gsnedders|work> | Darxus: What do you gain by using a custom schema language to writing it all in code yourself? |
| 18:16 | <Darxus> | gsnedders|work: The ability to then write schemas for other things in that language. |
| 18:17 | <Darxus> | http://www.oreillynet.com/xml/blog/2007/01/diagram_comparing_schema_langu.html - ven-ish diagram of schema language capabilities. |
| 18:17 | <Philip`> | Hopefully nothing else in the world is as crazy as HTML5 and needing the same kind of schema language features |
| 18:17 | <gsnedders|work> | Darxus: What do you gain by being able to express data type restrictions in a schema? |
| 18:17 | <Darxus> | It seems like there should be a schema language that contains all of them plus the ability to validate HTML5. |
| 18:17 | <gsnedders|work> | Philip`: Atom Syndication Format can't be expressed in any either, AFAIK |
| 18:17 | <gsnedders|work> | Philip`: Actually, that's untrue. |
| 18:18 | <gsnedders|work> | Philip`: It isn't expressed fully by the included RelaxNG schema. |
| 18:18 | <Darxus> | gsnedders|work: Also, hopefully it would make it easier to update an HTML5 validator for HTML5.1. |
| 18:18 | <gsnedders|work> | Philip`: But you can express it fully if you combine that with Schematron |
| 18:18 | <Philip`> | gsnedders|work: I assume it doesn't need the ability to e.g. express table constraints, though |
| 18:18 | <gsnedders|work> | Philip`: But that still doesn't limit atom:updated, atom:published, etc. to being valid dates |
| 18:19 | <gsnedders|work> | Oooo! Tests have finished running! |
| 18:19 | gsnedders|work | goes back to work |
| 18:20 | <inimino> | Darxus: what happens if HTML5.1 adds new conformance criteria that are inexpressible in the new language? |
| 18:20 | <Philip`> | gsnedders|work: You need to write more tests, so you can spend more time on IRC waiting for them to finish |
| 18:20 | <Darxus> | inimino: Then I extend the new language. |
| 18:30 | <Darxus> | A machine readable version of the HTML5 spec would be much more difficult if it were not for recursion. |
| 19:37 | <ap> | Hixie: is the idea of using Upgrade header for WebSocket based on something web servers can do today? We're adding test infrastructure for WebSocket now, and I wonder if we can make it work inside Apache easily |
| 19:40 | <gsnedders|work> | ap: I think I heard someone talking about an Apache module for it |
| 19:42 | <ap> | gsnedders|work: googling suggests more like "venting about the lack of thereof", http://www.pmsenthilkumar.blogspot.com/2009/07/apaches-html5-websocket-conundrum.html :) |
| 19:43 | jwalden | needs to get around to writing a websocket server |
| 19:43 | <gsnedders|work> | ap: I mean about actually writing one themselves :) |
| 19:44 | <ap> | jwalden: we have an initial version at https://bugs.webkit.org/show_bug.cgi?id=27490 - not integrated with Apache in any way, though |
| 19:45 | <jwalden> | ap: I think the initial plan is for me to hack our web server enough to be able to implement the parsing, although it would also be lax and accept HTTP-style constructs that aren't also websocket |
| 19:45 | <jwalden> | eventually want something super-strict to throw out ill-formed inputs, tho |
| 20:18 | <Darxus> | Hah, HTML5 can't be valid XML because it doesn't allow associating a DTD. Which is required for valid XML. |
| 20:21 | <ttepass-> | Darxus, <!DOCTYPE html> is a valid doctype declaration per XML, isn't it? |
| 20:23 | <Darxus> | ttepass-: It is a valid doctype, but XML is not valid if it does not specify (and validate with) a DTD. |
| 20:23 | <takkaria> | it's still wellformed, though, and you can still validate it. :) |
| 20:24 | <ttepass-> | Ah: ?Note that it is possible to construct a well-formed document containing a doctypedecl that neither points to an external subset nor contains an internal subset.? |
| 20:24 | <Darxus> | "The XML Recommendation says that an XML document is 'valid' if it has an associated document type declaration and if the document complies with the constraints expressed in it." |
| 20:25 | <Darxus> | takkaria: Yes you can validate it against another schema but that still, apparently, makes it invalid xml. |
| 20:25 | <takkaria> | it doesn't make it invalid |
| 20:25 | <Darxus> | Quote from http://perl-xml.sourceforge.net/faq/ section 6. |
| 20:25 | <takkaria> | it just means that it's neither valid nor invalid |
| 20:25 | <Darxus> | I'm looking for the wording in the XML Recommendation. |
| 20:26 | <ttepass-> | Darxus, section 2.8: |
| 20:26 | <ttepass-> | [Definition: An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it.] |
| 20:27 | <Darxus> | "An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it" - http://www.w3.org/TR/REC-xml/ section 2.8 |
| 20:27 | <Darxus> | Yeah... |
| 20:27 | <Darxus> | I interpret that as meaning that it is invalid without specifying a DTD. |
| 20:29 | <takkaria> | I think you're misinterpreting |
| 20:30 | <takkaria> | it would be silly to make documents without a DTD invalid, since having a DTD is optional |
| 20:32 | <Philip`> | Is there any reason to prefer <html dir=rtl> over/under <style>html { direction: rtl }</style> ? |
| 20:32 | <Darxus> | Wow, validator.w3.org won't do just xml? |
| 20:35 | <annevk2> | Philip`, style sheets are optional |
| 20:36 | <ttepass-> | Non-CSS-user agents one would think. Like a search engine which want's to display the first n sentences and needs directionality for display. |
| 20:37 | <cying> | dear whatwg |
| 20:37 | <cying> | when a video element is appended to the DOM, should it trigger a load event? |
| 20:39 | <gsnedders> | cying: A load event on what? |
| 20:39 | <cying> | gsnedders: on the video element |
| 20:39 | <gsnedders> | cying: That'll fire once the video is loaded, no? |
| 20:39 | <cying> | http://satine.org/research/webkit/tests/video-events.html |
| 20:40 | <Rik|work> | cying: how does it behave on firefox ? |
| 20:40 | <cying> | Rik|work: ah i should try that |
| 21:26 | <Darxus> | Parse::Simple is upsetting me: "Entity 'lt' not defined". |