| 01:56 | Philip` | sees https://bugzilla.mozilla.org/show_bug.cgi?id=214476 with part of the HTML5 tokeniser state machine |
| 08:06 | <hsivonen> | mrbkap: parsetree.validator.nu isn't running the trunk of the Validator.nu parser (because I haven't fixed all the fallout from implementing SVG and MathML yet) |
| 08:34 | <gDashiva> | So this XSLT entry in bugzilla... it is being argued that using XSLT to output XHTML (instead of HTML) is an inferior solution. |
| 08:35 | <Lachy> | what the? One of Rob's bugs got marked ASSIGNED?! |
| 08:36 | <Lachy> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=5772 |
| 08:36 | <hsivonen> | Hixie: I think the point of aggregating content is that you actually aggregate it instead of putting it in an iframe |
| 08:54 | <takkaria> | jmb: ping. I'm thinking the best way to add ns support to hubbub is to add an enum to hubbub_tag which has the possible namespaces the spec says you can create elements in |
| 08:54 | <takkaria> | oh, wrong channel, sorry. :) |
| 08:55 | <hsivonen> | takkaria: how does the libxml2 tree impl. represent namespaces? |
| 08:56 | <takkaria> | hsivonen: AFAICT, it passes around strings |
| 08:56 | <hsivonen> | takkaria: ok. |
| 08:56 | <jmb> | takkaria: heh |
| 08:57 | <hsivonen> | fwiw, it sucks when an XML API doesn't required namespaces to be interned in some way and lots and lots of string compares happen on the namespace |
| 08:58 | <takkaria> | yeah, I want to avoid string compares |
| 08:58 | <takkaria> | if libxml2 needs things converted to strings, that can be done easily enough in the hubbub<->libxml2 binding |
| 09:08 | <Hixie> | hsivonen: it'll be in the same source document, just not in the same Document object |
| 09:15 | <hsivonen> | Hixie: if you had an HTML5-based blog and it showed automatic extracts of other blogs linking to you, would you put the extracts in iframes or would you sanitize the fragments heavily not to contain id or class attributes? |
| 09:18 | <Hixie> | iframes |
| 09:18 | <Hixie> | sandbox baby |
| 09:36 | <hsivonen> | Hixie: fwiw, xmlns talisman checking is one of the things that block me from deploying the parser trunk in the validator, so I'm allowing the xmlns talisman on any HTML element at least for now |
| 09:37 | <Hixie> | hm? |
| 09:37 | <Hixie> | oh because your pipeline doesn't support xmlns="" all the way through? |
| 09:37 | <Hixie> | or? |
| 09:38 | <hsivonen> | Hixie: the pipeline doesn't support xmlns as attributes, so I'm doing the check in the tree builder |
| 09:39 | <Hixie> | right |
| 09:40 | <Hixie> | how do you handle xmlns:foo ? |
| 09:40 | <Hixie> | (e.g. on <embed>) |
| 09:40 | <hsivonen> | Hixie: there's a bug now |
| 09:40 | <Hixie> | or data-:foo="" |
| 09:41 | <hsivonen> | Hixie: those are invalid, so it's not a problem if the RELAX NG validator whines |
| 09:41 | <hsivonen> | Hixie: the problem is expressing valid things that are bogus in XML |
| 09:41 | <Hixie> | really? |
| 09:41 | <hsivonen> | of and the data thing doesn't matter, because data- is magic alreday |
| 09:41 | <hsivonen> | s/of/oh/ |
| 09:42 | <Hixie> | i thought <embed xmlns> and data-:foo="" were both valid |
| 09:42 | <hsivonen> | xmlns:foo never is unless foo==xlink and in foreign |
| 09:43 | <Hixie> | where does the spec say that? |
| 09:43 | <hsivonen> | ooh. <embed>! |
| 09:44 | <Hixie> | right |
| 09:45 | <hsivonen> | that sucks |
| 09:45 | <Hixie> | <embed *> and data-* are the two places attributes are unconstrained |
| 09:45 | <hsivonen> | Hixie: but common attributes and aria-* are constrained on embed, right? |
| 09:46 | <Hixie> | common attributes yes |
| 09:46 | <Hixie> | aria-*, dunno, haven't yet seen a sane spec for those |
| 09:46 | <hsivonen> | Hixie: well, aria-* should be, right? |
| 09:46 | <Hixie> | (nor have i looked; a sane spec might exist) |
| 09:46 | <Hixie> | aria-* seem like they would be treated as common attributes, yes |
| 09:47 | <hsivonen> | Hixie: fwiw, I'd expect an aria state that isn't applicable to the current role of <embed> to be invalid on embed |
| 09:48 | <hsivonen> | Hixie: the tricky question is what to do with aria-bogus on embed |
| 09:48 | <hsivonen> | should that be valid or invalid? |
| 09:48 | <Hixie> | right, i'd expect most aria-* things that contradict html semantics to be invalid |
| 09:48 | <Hixie> | aria-* is a defined set of attributes, right? |
| 09:48 | <zcorpan> | Hixie: yes |
| 09:48 | <Hixie> | so aria-bogus isn't in aria-* |
| 09:49 | <hsivonen> | Hixie: aria-* is a finite set |
| 09:49 | <zcorpan> | Hixie: right, but <embed> allows any attributes |
| 09:49 | <hsivonen> | Hixie: but aria-bogus is reserved for future ARIA |
| 09:49 | <Hixie> | oh i see what you're asking |
| 09:49 | <hsivonen> | zcorpan: so in that sense, aria-* is infinite |
| 09:49 | <Hixie> | i don't like the idea of reserving attributes personally |
| 09:49 | <hsivonen> | s/zcorpan/Hixie/ |
| 09:49 | <Hixie> | and would be fine with just not worrying about it |
| 09:50 | <hsivonen> | Hixie: umm. you are reserving everything but data-*! |
| 09:50 | <Hixie> | not on <embed> |
| 09:51 | <hsivonen> | anyway, handling <embed> sucks |
| 09:51 | <Hixie> | s'what you get for using an xml pipeline and schemas :-D |
| 09:52 | <hsivonen> | Hixie: I blame namespaces for making some attributes special |
| 09:52 | <Hixie> | i blame namespaces for a lot of things :-) |
| 09:52 | <Hixie> | but that doesn't help us :-) |
| 09:53 | <hsivonen> | Hixie: we could help ourselves by not insisting that xmlns:foo be non-special |
| 09:54 | <zcorpan> | from a practical point of view, i'd like to know that i've typoed aria-disalbed on <embed> |
| 09:54 | <hsivonen> | zcorpan: good point |
| 09:54 | <zcorpan> | whether it's a warning or error matters less to me |
| 09:54 | <hsivonen> | zcorpan: although if you've typoed class, you wouldn't know |
| 09:54 | <Hixie> | from a practical point of view, i doubt any aria-* attributes are going to have a useful result on <embed> |
| 09:54 | <zcorpan> | hsivonen: true |
| 09:55 | <Hixie> | and if you care about accessibility, <embed> probably isn't going to even appear in your document |
| 09:55 | <zcorpan> | i guess the only aria attribute you'd use on embed, if anything, is role="presentation" |
| 09:56 | <hsivonen> | Hixie: if ARIA really never makes any sense whatsoever on <embed> (i.e. the plug-in always drives the accessibility API including the node for <embed> itself), then I'd prefer to see ARIA non-conforming on <embed> |
| 09:56 | <Hixie> | hsivonen: well like i said, i've yet to see a useful description of aria in html |
| 09:56 | <Hixie> | hsivonen: so i can't really make educated comments about aria |
| 09:57 | <Hixie> | as it stands now, html5 doesn't even acknowledge that aria exists |
| 09:57 | <hsivonen> | Hixie: which is a problem given all the discussions that assume that HTML5 will import aria-* |
| 09:58 | <jgraham> | Doesn't something like ariia-describedby make sense on <embed>? |
| 09:59 | <hsivonen> | Hixie: even if details are left for later, it would be nice to have a red box acknowledging the intent to import ARIA into common attributes |
| 09:59 | <Hixie> | i've already told the aria group that if they want html5 to import aria, aria needs to get its act together and define how it works in html5-levels of detail |
| 09:59 | <hsivonen> | jgraham: yes, if it is implementable in a sane way in a situation where the plug-in talks to the accessibility API, too. |
| 10:00 | <jgraham> | hsivonen: Why would the plugin need to talk to the accessibility API? |
| 10:00 | <hsivonen> | jgraham: to make the plug-in content navigable through AT |
| 10:01 | <hsivonen> | jgraham: Ideally, the accessible tree of Flash content should appear as a subtree of the HTML document's accessible tree without the user having to care about the integration point |
| 10:02 | <jgraham> | I thought that aria-describedby was for descriptions, no? It seems like you could describe the contents of the plugin even in the case that you couldn't actually use it, though clearly it would be better to actually be able to use it |
| 10:03 | <zcorpan> | i don't really understand the use-case for aria-describedby |
| 10:03 | <hsivonen> | jgraham: I think you can have descriptions for stuff that can also be further examined by AT |
| 10:07 | <jgraham> | hsivonen: I don't think it's clear that there are supposed to be any restrictions on what can have an aria-describedby which sort of makes sense since the develop might have no knowledge of what the AT can interact with |
| 10:10 | jgraham | likes how the aria spec says: Property: "labelledby [...] A related concept is label in HTML" but also says "Property: describedby: [...] A label should provide the user with the essence of the what the object does whereas describedby is intended to provide additional information which some users might need [...] HTML label element, and HTML table cell headers are de facto describedby values" |
| 10:11 | <Hixie> | that's about this |<------------------------------------------->| far from being good enough to be integrated with html5 |
| 10:11 | <annevk> | de facto? |
| 10:12 | <annevk> | hah |
| 10:12 | annevk | is at reboot10 |
| 10:12 | annevk | wonders if the WiFi dropped again :) |
| 10:12 | <Hixie> | hey anne |
| 10:12 | <jgraham> | The aria spec really sucks |
| 10:12 | <jgraham> | indeed |
| 10:12 | <jgraham> | Or to rearrange into the sentence I was aiming for, "Indeed, the aria spec really sucks" |
| 10:15 | <annevk> | ah, so I'm still online, I receive your messages in blobs |
| 10:15 | <zcorpan> | so there's new Image() and new Audio() but no new Video() |
| 10:17 | <annevk> | hi Hixie |
| 10:18 | <Hixie> | zcorpan: new Image() is there for historical reasons, like new Option(); new Audio() is there because you will likely want to play with audio without thinking of it as an element |
| 10:23 | <Philip`> | Do any tests for Audio/<audio> exist yet? |
| 10:23 | <Philip`> | (Audio was pretty broken when I last played with it in Opera) |
| 10:23 | <Hixie> | i know of no tests |
| 10:25 | <zcorpan> | i have a few very basic tests |
| 10:26 | <zcorpan> | testing <video> and <audio> at the same time |
| 10:26 | <zcorpan> | http://simon.html5.org/test/html/dom/interfaces/HTMLElement/HTMLMediaElement/ |
| 10:27 | <annevk> | I have tests for new Audio() somewhere but I'm not sure if they're still valid with the new API |
| 10:28 | <Philip`> | Okay, thanks |
| 10:29 | <Philip`> | I think the problems I had were with trying to play the same sound file multiple times |
| 10:29 | <Philip`> | which ought to mix everything together but in Opera it only played one at a time |
| 10:30 | <othermaciej> | we have some in the WebKit regression tests, though they are not thorough compliance tests or anything |
| 10:30 | <Hixie> | i've passed the 50% mark in my big URLification project |
| 10:38 | <roc> | doublec is writing some |
| 10:40 | <Philip`> | What <audio> really needs is a spectrum analyser API |
| 10:40 | <roc> | graphic equalizer in every tab |
| 10:42 | <Philip`> | I want a web page with DOM nodes bouncing around in time with the background music |
| 10:43 | <Hixie> | that would be cool indeed |
| 10:43 | <Hixie> | send mail |
| 10:43 | <Hixie> | i'll get right on punting that to v3 |
| 10:44 | <mrbkap> | Philip`: Because hamsters randomly bouncing around in the background isn't enough? They have to be in time with the music now too? |
| 10:44 | <Philip`> | Actually it could just expose the raw sample data, then you can write an FFT in JavaScript |
| 10:45 | <Hixie> | web 2.0 hamster dance: now in time with the music. |
| 10:45 | <hsivonen> | shoudn't they be badgers? |
| 10:45 | <doublec> | someone sent me a vorbis decoder in javascript - with raw sample data that would be useful :) |
| 10:45 | <Lachy> | oh, drawing visualations on canvas would be awesome |
| 10:46 | <hsivonen> | doublec: does it perform in real time on today's hardware? |
| 10:46 | <Hixie> | Philip`: you could implement the fft server-side, and use xhr to get each sample frame analysed, for extra web 2.0ness |
| 10:46 | <Philip`> | mrbkap: I thought the point of APNG was that the old animated hamster GIFs could now be rendered in full 24-bit colour |
| 10:46 | <Philip`> | so clearly this is the direction that the technology is evolving in |
| 10:47 | <mrbkap> | "Web 2.0, supporting more colorful, rhythmic hamsters" |
| 10:47 | <doublec> | hsivonen: it's actually actionscript and works in real time on the flash player. I've modified it to get it running on tamarin but haven't got it actually playing real sound yet. |
| 10:47 | <hsivonen> | doublec: cool. |
| 10:48 | <Philip`> | hsivonen: Badgers don't dance - only hamsters do |
| 10:48 | <Lachy> | if you're doing the analysis server side, you could just download a single file with all the data in it and just keep the audio and visualation synchronised. |
| 10:48 | <doublec> | as long as 'todays hardware' is dual core machine not doing anything but decoding a single file |
| 10:48 | <Lachy> | Philip`, could you build a demo site using such a workaround? |
| 10:49 | <Philip`> | Lachy: How would you keep them synchronised? |
| 10:49 | <Lachy> | time indexes |
| 10:50 | <Hixie> | use the flash plugin to listen to the music using the user's microphone |
| 10:50 | <Hixie> | and use that to sync the visual |
| 10:50 | <Philip`> | Synchronisation seems hard when you're using setTimeout with 16ms resolution |
| 10:52 | <Lachy> | if you frequently query the currentTime of the audio, you can adjust for any discrepencies |
| 10:52 | <Lachy> | as long as it doesn't drift too far out of sync to be perceptable to the user, it's not a big problem. |
| 10:53 | <Philip`> | Hixie: That wouldn't work for me, since I use earphones |
| 10:53 | <Hixie> | ah well |
| 10:53 | <Hixie> | the best plans of mice and men, et al |
| 10:57 | <Hixie> | @#$%(&!@# |
| 10:58 | <Lachy> | ? |
| 10:58 | <Hixie> | window.open('http://{', 'x') does nothing if frame 'x' is an iframe, and shows an error if it has to open a new window |
| 10:58 | <Hixie> | except in firefox |
| 10:59 | <Hixie> | oh, and IE |
| 10:59 | <Hixie> | that'll teach me to test in reverse order of market share |
| 10:59 | hsivonen | considers filing a spec bug about the infoset mappability of the attributes on <embed> and data-* attributes |
| 10:59 | <Hixie> | nevermind! |
| 10:59 | <Hixie> | i have to say, bugzilla makes rejecting bugs much more satisfying |
| 11:00 | <Hixie> | and, frankly, easier |
| 11:00 | <hsivonen> | Hixie: are you implying you'd reject a bug about infoset mappability? |
| 11:00 | <gDashiva> | And much more .. cyclic |
| 11:00 | <gDashiva> | resolve, reopen, resolve, reopen, the dance goes on until someone calls mike |
| 11:01 | <Hixie> | hsivonen: i wasn't trying to imply that, no |
| 11:01 | <Hixie> | with bugzilla, i can say "i agree" and mark the bug WONTFIX at the same time |
| 11:01 | <Hixie> | in e-mail, if i say "i agree", then it's assumed that i am not rejecting the request |
| 11:02 | <Hixie> | hsivonen: i'm not sure i really care about infoset mappability, though |
| 11:02 | <Hixie> | hsivonen: do you mean xml/html roundtripping? |
| 11:02 | Hixie | has never been really sold on the value of xml/html roundtripping |
| 11:02 | <hsivonen> | Hixie: *you* may not care about it directly, but if the party line is "just stick an HTML5 parser at the front of your XML pipeline", perhaps it should matter |
| 11:03 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/spec.html is produced via XML/HTML roundtripping |
| 11:03 | <Philip`> | but that's just because the XML version is far quicker to parse repeatedly |
| 11:04 | <Hixie> | it has certainly had a higher cost to maintain the fiction that the set of documents serialisable to html is the same as the set of documents serialisable to xml than i first anticipated |
| 11:05 | <Hixie> | hsivonen: i don't understand why the xml pipelines are so constrained to the infosets that the xml syntax allows |
| 11:05 | <Hixie> | hsivonen: why do xml pipelines enforce "tag names can't contain spaces", for instance? surely that's just excess code that isn't helping anyone |
| 11:05 | <Hixie> | hsivonen: i mean, the parser should enforce that, sure |
| 11:06 | <Hixie> | hsivonen: but once it's parsed, who cares |
| 11:06 | <hsivonen> | Hixie: some people (rightly) don't want pipelines to silently serialize stuff that can't be parsed back with a conforming XML 1.0 parser |
| 11:06 | <zcorpan> | hsivonen: but shouldn't that be part of the serializer? |
| 11:07 | <Hixie> | i understand that the serialiser would want to verify conformance of its output |
| 11:07 | <hsivonen> | zcorpan: that's a design decision which isn't *our* design decision |
| 11:07 | <hsivonen> | for example, XOM throws early |
| 11:07 | <Hixie> | but enforcing the serialiser's constraints in the pipeline itself seems like bad design to me |
| 11:07 | <Hixie> | anyway |
| 11:08 | <Philip`> | zcorpan: It's much easier for debugging if it complains immediately when unserialisable content is inserted into the document, rather than silently accepting it and then complaining thousands of lines of code later when you try serialising |
| 11:08 | <hsivonen> | Hixie: it seems sensible design in some sense, although it makes no sense for perf |
| 11:08 | <Hixie> | maybe we should just define a set of mutations to the "infoset" that html parsers can apply if they are going to be used with these overconstraining xml-biased pipelines |
| 11:08 | <zcorpan> | i guess it could make sense if all you have to deal with is xml |
| 11:09 | <Hixie> | (with the understanding that these mutations would be destructive) |
| 11:09 | <hsivonen> | zcorpan: obviously, all text/html from "out there" can't be losslessly mapped to XML 1.0 (4th ed. or earlier), but it's yucky in principle if conforming docs also expose the problems |
| 11:09 | <Philip`> | zcorpan: That seems sensible since all most people have to deal with is XML; it's just HTML that thinks it's a special case and doesn't fit in with the proper world-view |
| 11:12 | <hsivonen> | Hixie: I intend to ship a set of mutations, but it isn't theoretically pure to have to apply those to conforming docs |
| 11:12 | <Hixie> | i long ago gave up on things being theoretically pure |
| 11:13 | <hsivonen> | Hixie: then you can allow the xmlns talisman regardless of tree position :-) |
| 11:13 | <Hixie> | i was going to :-) |
| 11:13 | <hsivonen> | great :-) |
| 11:13 | <Hixie> | (hence the bug being assigned, not wontfixed :-) ) |
| 11:14 | <Hixie> | assigned = i will do something |
| 11:15 | hsivonen | starts fixing the infoset coercion regressions introduced by the SVG/MathML work |
| 11:16 | <hsivonen> | with the xlink fixup, the decision needs to be deferred until the tree builder |
| 11:22 | <Hixie> | http://www.w3.org/mid/op.udcpa1lp6hl8nm⊙cmau seems to miss the point a little |
| 11:56 | <hsivonen> | Hixie: fwiw, the non-NCName munging I implemented is "_nonxml_" followed by the name escaped as UTF-8 and a-z and '-' passed through literally and other bytes escaped as two uppercase hex digits each, finally followed by "_" |
| 11:58 | <hsivonen> | actually, that's not good |
| 12:01 | <hsivonen> | I like it that the HTML5 spec now has a one-stop place to copy and paste namespace URIs from |
| 12:04 | <zcorpan> | hsivonen: shouldn't the "nonxml" part be uppercase so that it's possible to distinguish between <a #> and <a _nonxml_23>? |
| 12:05 | <zcorpan> | i mean <a _nonxml_23_> |
| 12:05 | <hsivonen> | zcorpan: actually, I think the _noxml_ part should be a namespace that the parsing algorithm doesn't otherwise output |
| 12:05 | <zcorpan> | why? |
| 12:06 | <hsivonen> | zcorpan: that way I don't need to check for collisions with _noxml_ actually appearing in the input |
| 12:06 | <zcorpan> | uppercase can't appear in the input |
| 12:06 | <hsivonen> | zcorpan: excellent point |
| 12:06 | <hsivonen> | zcorpan: thanks |
| 12:21 | <Lachy> | so much for WebApps being a public group! |
| 12:21 | <Lachy> | they moved the telcon to #waf to get away from krijnh's IRC logs. |
| 12:22 | <gDashiva> | They are a public group. They're just using the w3c definition of public. |
| 12:31 | <zcorpan> | so what was the [off] feature for? |
| 12:31 | <Lachy> | zcorpan, no idea |
| 12:31 | <Lachy> | I don't think anyone even bothered to announce that it was added on the mailing list. |
| 12:31 | <Lachy> | shepazu should have done that, since he pushed so hard for it |
| 13:30 | <shepazu> | Lachy: I wasn't sure about the status of the feature... maybe krijnh would like to speak on it? |
| 13:31 | <Lachy> | shepazu, what is there to discuss? It was enabled at your request for the #webapps channel, and AFAIK, is still enabled. |
| 13:32 | <Lachy> | but, at the moment, it seems krijnh currently isn't making the #webapps logs public anyway |
| 13:33 | <shepazu> | when last I heard, Lachy, he was still working on it... and the WG hasn't actually come to a decision on logging... I don't consider a deadline to be a very good criteria of agreement |
| 13:33 | <Lachy> | well, I think the whole issue is silly. The fact that it's a public group should be enough to make any logging, by anyone in the channel, acceptable. |
| 13:35 | <shepazu> | why? |
| 13:35 | <shepazu> | that's not clear a priori |
| 13:36 | <zcorpan> | s/group/channel/ |
| 13:36 | <shepazu> | the interesting thing for me the the different expectations of privacy... maybe a generational thing, or cultural? |
| 13:37 | <Lachy> | for me, public == public, not "public, but with secrets we need to hide" |
| 13:38 | <shepazu> | I was talking about this with friends, and the general sentiment was that private logging was one thing, but publishing logs (esp. when it's not absolutely clear that it's being logged) was invasive and rude |
| 13:39 | <Lachy> | if the topic includes a clear statement about their being public logs, there is no problem |
| 13:40 | <shepazu> | well, that's open to individual judgment... clearly, that's your view... but others might not thing so |
| 13:40 | <shepazu> | Lachy: every big company has secrets... why doesn't Hixie publish his Google research, for example? |
| 13:40 | <Philip`> | I think I gave up on the idea that my conversations should be unpublished by default when I realised that newsgroup posts from when I was 11 have been archived forever, so anything I say now shouldn't embarrass me more than anything I've said before :-) |
| 13:40 | <shepazu> | because he can't, legally |
| 13:40 | <shepazu> | Philip`: yeah, that's why I think it's a generational thing |
| 13:41 | <gDashiva> | So all the talk about being 'open' is just hand waving |
| 13:41 | <shepazu> | those of us who grew up before the Web tend to be a little more sensitive to privacy |
| 13:42 | <Philip`> | shepazu: He hasn't given details of his research to anyone outside Google, as far as I'm aware, which is quite different to giving details to a select group of people who have a higher status than all the other members of the public group |
| 13:42 | <zcorpan> | shepazu: if Hixie doesn't want to publish hsi research then he wouldn't paste the results in a public channel |
| 13:43 | <shepazu> | I'm just saying that "open" isn't black and white |
| 13:44 | <shepazu> | zcorpan: then without his raw research, we just have to trust that he is correct and giving the whole picture... that's a complex issue, too |
| 13:44 | <Lachy> | shepazu, there's a difference between choosing not to make something public, or saying it in a public channel and expecting it to be hidden |
| 13:45 | <shepazu> | yeah, but it's no more "ethical" to hide information than it is to reveal it to a select group, and it's no more pragmatic for the group's functioning |
| 13:47 | <zcorpan> | shepazu: indeed -- one way to verify his results would be to do an independent research and comparing the results |
| 13:47 | <Philip`> | shepazu: I would possibly view "open" as meaning that anyone can participate as equally as possible, which means all relevant information (like past discussions) needs to be made available to anyone - otherwise it would unfairly favour the closed group of people who are already members and have exclusive access to certain information |
| 13:48 | <Philip`> | But I might realise that's the wrong way to view things :-) |
| 13:49 | <gDashiva> | Maybe WCAG2 redefined open while they were making up all those funny terms |
| 13:49 | <shepazu> | Philip`: in a way, WHATWG is not open in this sense, because in order to come up to speed on 4 years of history and discussion, it would be a major undertaking... obscurity through profusion :) |
| 13:50 | <Lachy> | shepazu, wtf? |
| 13:51 | <zcorpan> | shepazu: how do you suggest to make it easier to come up to speed? |
| 13:51 | <Philip`> | shepazu: That problem seems to often occur in open source projects too - they can be technically open, in that you can see the code and bug reports and mailing lists and everything, but it can be far too hard for anybody to enter the group because it's too large and complex and poorly documented |
| 13:51 | <Lachy> | that's like the public library isn't open because it would be a major undertaking to read all the books in there. |
| 13:51 | <shepazu> | Philip`: yeah, same sort of thing |
| 13:51 | <shepazu> | zcorpan: dunno... it's a hard problem |
| 13:51 | <Lachy> | s/like/like saying/ |
| 13:52 | <shepazu> | I'm not ascribing blame or anything, just observing... openness is relative |
| 13:52 | <Philip`> | whereas other projects do provide good documentation, and tell you exactly how to check out the code and install dependencies and build and write simple patches and cope with the processes for filing bugs and committing code and whatever, which makes them much more open in the practical sense |
| 13:52 | <shepazu> | in a very real and pragmatic sense |
| 13:54 | <gDashiva> | There's a very important difference between something being naturally unopen (like a huge library) and intentionally closing down something that was open before (like moving your telcon) |
| 13:55 | <hsivonen> | shepazu: what does Hixie's research at Google have to do with WG openness? |
| 13:55 | <jgraham_> | Regardless of whether perfect openess is a viable goal, I still can't understand how people could object to logs of a *public* channel |
| 13:55 | <Philip`> | shepazu: In the WHATWG, I think it's quite possible to come up to speed quickly if you focus on a single component - most of the years of discussion are about all the other components and so you can ignore them entirely |
| 13:55 | <hsivonen> | shepazu: isn't it pretty clear that Hixie's research isn't 'open' and only the aggregate results or even just conclusions are disclosed? |
| 13:55 | <Philip`> | (At least that's what I did, by just looking at canvas stuff and ignoring everything else) |
| 13:56 | <Philip`> | (and then searching the mailing list and IRC logs for all previous discussions of it, which didn't take long) |
| 13:56 | <shepazu> | one reason the SVG WG has not been as quick as we'd have liked with the SVG-in-text/html thing is that we are busy with other things, but another major hurdle is that Hixie has constructed a complex and intricate set of criteria for HTML5 parsing and such, and it's taken us a while to grok it |
| 13:56 | <shepazu> | hsivonen: yes, that is absolutely clear :) |
| 13:57 | <shepazu> | Philip`: if I weren't busy with a ton of other things, that would be easier |
| 13:58 | <Philip`> | I suppose parsing is one of the least good components to focus on, since it's big and complex and has had loads of past discussion |
| 13:59 | <shepazu> | hsivonen: I'm just saying that no matter how "open" a group is, there are still secrets and hidden agendas among the parties... open minutes is actually not the hardest part of that problem |
| 13:59 | <shepazu> | Philip`: indeed :( |
| 13:59 | <shepazu> | and the rationales for things aren't always clear from the spec |
| 13:59 | <Philip`> | On the other hand, there's multiple people who generally understand it already and would be happy to respond to questions |
| 14:00 | <Philip`> | which is better than for most other features |
| 14:00 | <hsivonen> | shepazu: yeah, but I don't see how being secretive about the minutes helps, particularly if the group claims to do its work in public |
| 14:00 | <shepazu> | Philip`: yeah, lots of people are forthcoming, but sometimes facing the whole channel is not helpful... |
| 14:00 | <shepazu> | hsivonen: I understand what you're saying |
| 14:02 | <Philip`> | shepazu: Are the rationales for things *ever* clear from the spec? :-) |
| 14:02 | <Philip`> | A hundred years from now, most of the WHATWG members will be dead and nobody will be able to understand the reasoning behind the HTML5 spec and there will be nobody to explain it |
| 14:05 | <shepazu> | Philip`: that's one reason that good spec support documentation is important... also to "check your work" |
| 14:06 | <zcorpan> | Philip`: it seems reasonable to assume that there will be new people joining the work before we die |
| 14:06 | <zcorpan> | it's not like we're a fixed set of people and we need replacements when we die :) |
| 14:07 | <jgraham_> | The problem is that documenting everything that went in to forming a conclusion is orders of magnitude harder than just documenting the results. A certian amount of expediency is needed to make our work relevant |
| 14:07 | <Philip`> | zcorpan: The existing members won't perfectly transfer all their institutional memory to new members, so things will be forgotten and then will be lost forever since everyone was too lazy to write them down |
| 14:08 | <shepazu> | jgraham_: yeah, it's a balancing act |
| 14:11 | <jgraham_> | (I once read something by some sientists who suggested a "new method" for documenting code which was basically a chronology of all the design decisions that they tried and why they worked or didn't. In principle it sounds great, but the project they tried it on ended up with something like 800 pages of text most of which wasn't useul in figuring out how the end product worked) |
| 14:12 | <jgraham_> | s/sientists/scientists/ |
| 14:13 | <hsivonen> | shepazu: are there examples of other WGs working on large specs and documenting the design rationale on the level you'd like to see in HTML5? |
| 14:14 | <Philip`> | I think things like "Authors should not use JIS_X0212-1990, x-JIS0208, and encodings based on EBCDIC." are unpleasantly far from the balance - it should at least say they're discouraged because they are not ASCII compatible and so can result in security vulnerabilities when accidentally decoded ASCII-compatibly, or something like that |
| 14:15 | <shepazu> | hsivonen: yes and no... first, let me say that I'm not talking about documenting the entire design rationale, just key points that aren't obvious... right now, the spec is proscriptive, and not very descriptive |
| 14:15 | <Philip`> | and like "If the charset attribute is specified, the element must be the first element in the head element of the file." where it can say that that's to avoid problems where it has to parse text before it's reached the charset element, or something like that |
| 14:15 | <shepazu> | Philip`: exactly |
| 14:17 | <shepazu> | the SVG WG, having almost completely new participants, have seen how earlier rationales were lost with the old members, and have to sometimes backwards-engineer the spec... so we've taken to recording Resolutions and Rationales in our minutes, so we can have a short summary of why we decided particularly unintuitive or obscure things |
| 14:18 | <shepazu> | we're not perfect at it, but it's not been bad, and it does help |
| 14:18 | <shepazu> | then again, we operate as a group, not as a single editor... so I'm not sure it would work for HTML5 |
| 14:18 | <Philip`> | It seems the primary difficulty is getting someone to actually do the work |
| 14:19 | <shepazu> | but it does mean that most of us also understand pretty much most of the stuff we decide at a good level |
| 14:19 | <shepazu> | Philip`: you said it |
| 14:20 | <shepazu> | hard work, takes a certain set of aptitudes |
| 14:20 | <shepazu> | broad vision and strict attention to details |
| 14:20 | <Philip`> | particularly since this is not a group that will try to force people to do things they don't particularly want to |
| 14:21 | <shepazu> | Philip`: luckily for y'all, you have a huge worker base... |
| 14:21 | <Philip`> | shepazu: The number of participants doesn't help when 0% want to do the work :-) |
| 14:23 | <shepazu> | Philip`: at least it's not negative :) |
| 14:27 | hsivonen | is getting close to fixing everything that has regressed in the parser since last release |
| 14:42 | <Philip`> | If browsers implement worker threads, will they be actual real threads, so people can fully utilise quad-core CPUs to compute Mandelbrot fractals in JavaScript? |
| 16:34 | <hsivonen> | http://lists.w3.org/Archives/Public/www-html/2008Jun/0047.html |
| 16:38 | <zcorpan> | getElementsByName doesn't match <sup name> |
| 16:38 | <hsivonen> | http://lists.w3.org/Archives/Public/www-html/2008Jun/0061.html |
| 16:45 | <gsnedders> | Is there any documentation of any de-facto standards for tag parsing? |
| 16:45 | <hsivonen> | gsnedders: tag like etag? |
| 16:45 | <gsnedders> | hsivonen: Like Flickr's tags |
| 16:46 | <hsivonen> | gsnedders: I don't know. What else do you need except splitting on colon? |
| 16:46 | <hsivonen> | gsnedders: or do you want to implment UI input consistently with Flickr? |
| 16:46 | <gsnedders> | hsivonen: Well, what happens with stuff like "foobar" lol, "meep" |
| 16:47 | <hsivonen> | ah, you mean parsing the input field |
| 16:47 | <gsnedders> | yeah |
| 17:54 | <takkaria> | heh, one of the CS lecturers from my university is telling Hixie he's wrong in the URL thread |
| 17:54 | <Philip`> | I think everybody is telling Hixie he's wrong in the UR[IL] thread |
| 17:55 | <gsnedders> | Philip`: no, IRL! |
| 17:56 | <Philip`> | Sorry, the internet has already found a use for that TLA |
| 17:56 | <gsnedders> | IRI then? |
| 17:58 | <takkaria> | oh, Roy Fielding jumped in, awesome |
| 18:00 | <takkaria> | I don't know how that thread has gone on so long given that Hixie has said a few times that he'll just write the rules in HTML5 and be done with it |
| 18:13 | <hdh0> | http://camendesign.com/?200805291052 wants a Fx3 extension to convert flash video to <video> playing with VLC |
| 18:26 | <gsnedders> | does anyone have any stats about how common it is for optional tags to be omitted? |
| 18:34 | gsnedders | bursts out laughing at a very well hidden joke in the HTML 5 parsing section |
| 18:35 | <takkaria> | which one's that? |
| 18:35 | <gsnedders> | takkaria: The sarcasm end tag |
| 18:36 | <takkaria> | ah :) |
| 18:36 | <Philip`> | gsnedders: No |
| 18:36 | <gsnedders> | I mean, just skimming over the spec, you'd never even see that |
| 18:44 | <gsnedders> | What supports the mid URI scheme? |
| 18:51 | <takkaria> | hsivonen: when processing tokens "using the rules for the secondary insertion mode", if something in the secondary insertion mode changes the insertion mode, should that change the insertion mode or the secondary insertion mode? |
| 18:52 | <takkaria> | er, Hixie, even ^^ |
| 18:52 | <takkaria> | though I have a feeling either of you might know :) |
| 19:27 | <gsnedders> | Philip`, jgraham: I'll be in Cam next Thurs – Tues, if you care :P |
| 19:29 | <hsivonen> | takkaria: using the rules of the secondary mode doesn't in itself take you out of 'in foreign' |
| 19:30 | <hsivonen> | takkaria: btw, modeling 'in foreign' as an insertion mode makes sense if you insertion mode is a function pointer as in Hixie's impl |
| 19:30 | <hsivonen> | takkaria: but if you insertion mode is a switch condition, modeling 'in foreign' as an insertion mode totally sucks |
| 19:30 | <hsivonen> | and having it as a separate flag is *much* better |
| 19:31 | <takkaria> | hmm |
| 19:31 | <takkaria> | atm I'm using a switch |
| 19:31 | <hsivonen> | takkaria: then I suggest doing what I do :-) |
| 19:31 | <takkaria> | I'm still not quite sure what happens, though, if you use the secondary insertion mode and something in there changes the insertion mode. it changes the real insertion mode, yeah, not the secondary insertion mode? |
| 19:32 | <hsivonen> | having an 'in foreign' flag and a mode variable for the rest of the modes |
| 19:32 | <hsivonen> | and when the 'in foreign' flag is set, your usual mode variable is the secondary mode |
| 19:34 | <hsivonen> | takkaria: hmm. I don't think end tag processing can change the secondary mode without the rules also causing an exit from foreign content anyway |
| 19:34 | <hsivonen> | but now I'm not 100% sure |
| 19:34 | <hsivonen> | but that has been my assumption |
| 19:35 | <takkaria> | mm, I'm going with your assumption I think |
| 19:50 | <takkaria> | hsivonen: ah, you switch first on token type and then on state, hubbub does it the other way round |
| 19:54 | <hsivonen> | takkaria: token-major switches allow nice fall-throughs |
| 19:55 | <hsivonen> | (or, well, token-major callbacks) |
| 19:56 | <takkaria> | mm, that does seem to be the case |
| 19:57 | <takkaria> | ah well, I'm not changing hubbub now. :) |
| 20:00 | <takkaria> | I think that I can possibly implement the "in foreign" state as just calling the token handler again from inside itself |
| 20:38 | <hsivonen> | mrbkap: I updated http://parsetree.validator.nu/ to run the latest version of the parser |
| 20:41 | <Philip`> | hsivonen: No changes in comment parsing, I assume? |
| 20:42 | <hsivonen> | Philip`: I don't remember how old the previous deployment was, but it predated all the SVG and MathML work |
| 20:42 | <hsivonen> | Philip`: but most likely there haven't been comment parsing changes in that timeframe |
| 20:42 | <Philip`> | hsivonen: It'd be really nice if something like http://parsetree.validator.nu/?content=%3Ctest%3E worked |
| 20:42 | <gsnedders> | Philip`: I assume you don't care then :P |
| 20:44 | <Philip`> | gsnedders: I don't not care - I just assimilated the knowledge and didn't see a useful way to respond and then continued with the rest of my life :-) |
| 20:45 | <Philip`> | (unless it's not obvious that I'll be here over that time period too, in which case it may be useful for me to say so) |
| 20:46 | <hsivonen> | Philip`: perhaps tomorrow |
| 20:54 | hsivonen | wonders if <time> is principle-violating: http://twitter.com/t/statuses/843458747 |
| 20:58 | <Philip`> | It violates the principle of being valid HTML4 / XHTML1 |
| 20:58 | <hsivonen> | HTML4/XHTML1 validatity is overrated :-) |
| 20:59 | <hsivonen> | validity even |
| 21:01 | <Philip`> | Can you make <time> validate by sticking stuff in the DTD, or will that result in ugly "]>" stuff being rendered? |
| 21:02 | <Lachy> | Philip`, you have to create your own external DTD and use <!DOCTYPE html SYSTEM "htttp://.../my.dtd"> |
| 21:03 | <hsivonen> | Philip`: you could put stuff in an external DTD, but DTDs are overrated and passé |
| 21:07 | <hsivonen> | is the microformats community opposed to encoding variable values as classes? |
| 21:07 | gsnedders | commits with the message 'Bye-bye my dear "nymphet".' |
| 21:08 | <gsnedders> | (what is in that commit? hmm… who knows.) |
| 21:15 | hsivonen | also notes http://twitter.com/t/statuses/843517093 |
| 21:19 | hsivonen | thinks the abbr design pattern is more of an anti-pattern than putting variable data in class... |
| 21:20 | gsnedders | thinks it is less of an anti-pattern, but only marginally |
| 21:21 | <hsivonen> | the abbr design pattern would suck less it they replaced 'T' with ' ' and didn't put a non-Z TZD in there |
| 21:21 | <hober> | I think it depends on usage. <abbr title="2008-06-26">6/26</abbr> is one thing--<abbr title="2008-06-26T12:24:00-07:00">1 hour ago</abbr> is something else entirely. |
| 21:22 | <hsivonen> | yeah |
| 21:22 | <gsnedders> | <time> ftw! |
| 21:22 | <hober> | I really like the recent datetime-design-pattern work |
| 21:22 | <itpastorn> | It's modeled on vCard and therefore there is a "T" |
| 21:25 | <gsnedders> | ISO8601:2004 makes the T optional if agreed by both parties |
| 21:32 | <itpastorn> | And what would the other "party" be on the web that i am supposed to agrre with? |
| 21:32 | <itpastorn> | agree |
| 21:35 | <gsnedders> | The party who creates the date and the party who consumes the date, so in this case it would be agreed through the spec |
| 21:38 | <itpastorn> | My point is that there already are quite a few parsers on the market already. How would a spec change now work? There are many who would need to alter their apps. |
| 21:39 | <jgraham> | gsnedders: I assume you will also be in Cambridge even if I don't care :) |
| 21:39 | <gsnedders> | jgraham: s |
| 21:39 | <gsnedders> | or, if I don't press return accidentally… |
| 21:40 | <gsnedders> | seeming I have a train ticket down on the Wed evening, and a plane from STD on Tues… |
| 21:40 | <jgraham> | I'm away from Fri evening to Sun evening |
| 21:41 | <Philip`> | itpastorn: There's a party on the web? Nobody invited me :-( |
| 21:43 | <gsnedders> | itpastorn: Well, µf aren't really used enough to make such a change impossible |
| 21:45 | <itpastorn> | Yes, I actually agree. just wanted to play the devils adcocate.... |
| 21:47 | <itpastorn> | The party is in Spain (3-0 over Russia) |
| 22:02 | <krijnh> | shepazu, Lachy: the [off] thing works in #webapps |
| 22:02 | <krijnh> | Lachy: should I join #waf as well? ;) |
| 22:02 | <gsnedders> | itpastorn: (if we were talking about HTML, then I'd say it was impossible) |
| 22:03 | <krijnh> | Lachy: And I'm not logging the channel atm |
| 22:03 | <Lachy> | krijnh, no. The whole point of them moving the telcon to #waf was to avoid being in your logs |
| 22:03 | <krijnh> | Yeah, I read that :) |
| 22:03 | <mrbkap> | hsivonen: Cool, thanks. |
| 22:08 | <krijnh> | Left #webapps, cause it's not my intention to be a PITA :) If people don't want logs, that's fine by me |
| 22:08 | <krijnh> | Nn everybody |
| 22:20 | Philip` | wonders how long it's likely to take to build Firefox from Mercurial |
| 22:21 | <roc> | depends entlrely on hardware and OS |
| 22:22 | <roc> | fast dual-core Linux machine with 1GB of RAM: 20 minutes |
| 22:22 | <roc> | slow single-core Windows machine with 256MB RAM: all week |
| 22:23 | <Philip`> | I have 2.0GHz C2D / 2GB / Linux, and I started 20 minutes ago, so hopefully that means it won't take much longer :-) |
| 22:23 | <jcranmer> | Philip`: which directory is it building ATM? |
| 22:23 | <Philip`> | jcranmer: /home/philip/mozilla/mozilla/src/security/manager/ssl/src/nsPSMBackgroundThread.cpp |
| 22:24 | <jcranmer> | ah, you're nearly done then |
| 22:25 | <jcranmer> | I remember building on a machine with 256 MB as it agonized through libxul... happy days now |
| 22:25 | <roc> | yeah, the security module is the home stretch |
| 22:25 | <Philip`> | Oh, it's done |
| 22:26 | <Philip`> | 24 minutes |
| 22:28 | <Philip`> | Hooray, canvas text |
| 22:29 | <Philip`> | which changes size when you change the browser's text size :-( |
| 22:30 | <Philip`> | which means it's impossible to get predictable layouts |
| 22:32 | <roc> | that sounds like a bug |
| 22:33 | <roc> | file it. we have code in SVG to prevent that. |
| 23:29 | <jgraham> | smedero: The html5lib parse tree viewer now reports the version og html5lib it is using (well technically it reports the version of the working copy on the machine which isn't quite the same but it's probably close enough) |
| 23:50 | <smedero> | thanks! |
| 23:53 | <smedero> | yeah, that works for me at least. hopefully other people find it helpful... :) |