| 00:00 | <annevk> | cool, it actually works now :) |
| 00:00 | annevk | is happy |
| 00:06 | <annevk> | so most of the work was installing shitty python modules |
| 00:06 | <jgraham> | annevk: Don't you be dissing pyhon |
| 00:06 | <jgraham> | :) |
| 00:07 | <annevk> | :angel: |
| 00:07 | <annevk> | gsnedders, found a bug, you're not replacing [STATUS] everywhere |
| 00:08 | <annevk> | gsnedders, e.g., in style sheet links preceding the actual status |
| 00:11 | <Hixie> | dglazkov: ? |
| 00:12 | <dglazkov> | Hixie: there was this cool little concept you were explaining, oh, about 6 months ago that employed the idea of a "promise". |
| 00:12 | <dglazkov> | I can't remember the details -- that's where I had hoped you'd come in :) |
| 00:13 | <dglazkov> | this was related to an async API |
| 00:13 | <Hixie> | i have no idea what you're talking about :-) |
| 00:13 | <dglazkov> | damn |
| 00:13 | <dglazkov> | :) |
| 00:13 | <dglazkov> | ok, I'll scour the logs |
| 00:13 | <jgraham> | gsnedders: Replied |
| 00:16 | <jgraham> | Hixie: By the way re: labels on forms I can imagine wanting the browser to give me access to the fieldset legend when I was focussed on a label. That seems like the closest example to a nested table header that you would typically have |
| 00:17 | <Philip`> | dglazkov: Like Twisted's "Deferred", which represents a value that might not have been computed yet but it'll let you know once it has been? |
| 00:17 | <dglazkov> | Philip`: yes! |
| 00:17 | <dglazkov> | Philip`: thanks a bunch |
| 00:17 | dglazkov | has a research vector now |
| 00:19 | jgraham | has vauge recollections of not understanding that conversation at the time |
| 00:19 | <jgraham> | s/conversation/sonversation too well/ |
| 00:20 | <jgraham> | c |
| 00:20 | <Philip`> | gu |
| 00:20 | <annevk> | hmm, either dreamhost is slow or I should not generate the input form on the fly with python |
| 00:20 | <annevk> | anyway, Anolis ALPHABETA: |
| 00:20 | <annevk> | http://anolis.quuz.org/ |
| 00:24 | <jgraham> | annevk: No possibility to do a spec by uri? |
| 00:24 | <Hixie> | how do i give it a uri? |
| 00:24 | <Hixie> | um, what jgraham said |
| 00:25 | <annevk> | you can't |
| 00:25 | <Hixie> | man, you guys make my life hard :-P |
| 00:25 | <jgraham> | That seems like it should be easy... |
| 00:25 | <annevk> | it is easy |
| 00:25 | <annevk> | but i didn't need it :) |
| 00:25 | <annevk> | sigh ok, more complex UI |
| 00:26 | <Philip`> | annevk: Why do I get an internal server error if I try to run it on "<script>"? |
| 00:26 | <Hixie> | i can always generate the postdata clientside but that seems excessively complicated :-) |
| 00:26 | <annevk> | Philip`, I don't know |
| 00:27 | <Philip`> | annevk: Check the error logs? :-) |
| 00:28 | <Hixie> | um, are you using html5lib? it's pretty slow |
| 00:28 | <Hixie> | and it's missing a DOCTYPE :-) |
| 00:28 | <annevk> | it's using lxml |
| 00:28 | <Hixie> | wow |
| 00:29 | <Hixie> | i thought it was fast with lxml |
| 00:29 | <Hixie> | and it has a mysterious <meta http-equiv="content-type" content="text/html; charset=UTF-8"> |
| 00:29 | <annevk> | that could be the lxml serializer |
| 00:29 | <Hixie> | oooh, the IDs look much more promising |
| 00:30 | <annevk> | status: alphabeta |
| 00:30 | <annevk> | Philip`, might be somewhere in toc.py because of reversed?! |
| 00:30 | <annevk> | Philip`, seems like a gsnedders problem :) |
| 00:30 | <Hixie> | looks like it doesn't do the wordwrapping like bert's does, either, awesome |
| 00:31 | <jgraham> | I thought it used the html5lib serializer |
| 00:31 | <annevk> | jgraham, i can pick the serializer myself |
| 00:31 | <jgraham> | Oh OK. The html5lib serializer shouldn't be as slow as the parser |
| 00:31 | <annevk> | jgraham, and i just copied some lxml code |
| 00:32 | <jgraham> | So fromFile just returns a tree? |
| 00:32 | <Philip`> | The html5lib serialiser is quite a lot slower than lxml's |
| 00:32 | <jgraham> | Philip`: How much? |
| 00:32 | <Philip`> | jgraham: Quite a lot |
| 00:33 | <Philip`> | jgraham: At least multiple seconds difference, which was enough for me to change my spec-splitter to use lxml's serialiser instead by default |
| 00:34 | <jgraham> | It looks like it's maybe a factor of ~5 slower |
| 00:34 | <Philip`> | but it's not that bad really, and I was just impatient at the time |
| 00:34 | <jgraham> | It hasn't been optimized much I guess |
| 00:35 | <jgraham> | Anyway /me -> bed |
| 00:35 | <Hixie> | nn |
| 00:46 | <annevk> | Hixie, http://anolis.quuz.org/?url=... |
| 00:47 | <Hixie> | cool |
| 00:47 | <annevk> | no UI yet |
| 00:47 | Hixie | tries |
| 00:48 | <annevk> | Web Workers source seems to work (without heading) and Web Forms 2.0 source doesn't as there's a duplicate <dfn> error |
| 00:48 | <Hixie> | takes 10s |
| 00:48 | <annevk> | but I haven't figured out a way to give error information back so currently it will just say FAIL (... failed) |
| 00:48 | <Hixie> | better than bert's i guess :-) |
| 00:49 | <Hixie> | hm, there's a flag you need to flip for html5 |
| 00:49 | <Hixie> | something about w3c-compatible placement of <a> elements in <code> elements |
| 00:50 | <annevk> | ah, --w3c-compat-xref-a-placement |
| 00:50 | <Hixie> | sounds right |
| 00:50 | <annevk> | flipped |
| 00:51 | <Hixie> | thx |
| 00:51 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/temp.index |
| 00:51 | <Hixie> | taks 10s to generate |
| 00:52 | <annevk> | gsnedders said he did it in less I believe, but maybe DreamHost is slowing things down |
| 00:52 | <Hixie> | can you set --indent-char to a " " character too? |
| 00:52 | <annevk> | i already did |
| 00:53 | <annevk> | and it works, no? |
| 00:53 | <Hixie> | didn't check :-) |
| 00:53 | <Hixie> | thanks :-) |
| 00:53 | <Hixie> | i'm just going down the documentation |
| 00:53 | <annevk> | first thing I changed :) |
| 00:55 | <Hixie> | :-) |
| 00:58 | <Hixie> | what's <!--begin-link--> for? |
| 00:58 | <Hixie> | thanks for setting this up btw |
| 00:59 | <Hixie> | now i'm tempted to just update the spec even though i'm half-way through edits |
| 00:59 | <annevk> | I wouldn't start relying on it just yet, but I suppose you can |
| 01:00 | <annevk> | <!--begin-link-->http://whatwg.org/<!--end-link-->; turns into <a href="http://whatwg.org/">http://www.whatwg.org/</a>; I believe |
| 01:00 | <Hixie> | ah |
| 01:01 | <annevk> | mostly useful for previous version links and such |
| 01:01 | <annevk> | anyway, bedtime here |
| 01:01 | <Hixie> | nn |
| 01:01 | <annevk> | g'night |
| 01:02 | <Hixie> | Philip`: will your script just work if i use the new specgen? |
| 01:05 | <Philip`> | Hixie: No |
| 01:05 | <Hixie> | k |
| 01:06 | <Hixie> | consider this the warning you asked for then :-) |
| 01:06 | <Philip`> | It won't break horribly, but it won't split things into the proper sections |
| 01:06 | <Philip`> | I just need to upload an updated version to make it work with the new section names, which should be easy enough |
| 01:10 | <Hixie> | well the new one is definitely faster than bert's |
| 01:10 | <Hixie> | Philip`: i'm now autogenning the spec to http://www.whatwg.org/specs/web-apps/current-work/index-new |
| 01:10 | <Hixie> | so you can start fetching the file there whenever you're ready |
| 01:11 | <Hixie> | and then at some point we'll synchronise a switchover together and i'll take out the older version |
| 01:11 | <Hixie> | oh annevk |
| 01:11 | <Hixie> | do i need to do anything special to get a pubrules compliant version? |
| 01:11 | <Hixie> | i guess not |
| 01:11 | <Hixie> | nevermind. |
| 01:12 | <Hixie> | ohhh, the <meta> element came from the upload i did |
| 01:15 | <Hixie> | woah |
| 01:15 | <Hixie> | took 33 seconds that time |
| 01:16 | <Hixie> | and if you want to prepare for the w3c version, the new one is at http://www.whatwg.org/specs/web-apps/current-work/.w3c-new/Overview.html |
| 01:18 | <Hixie> | 83 seconds! |
| 01:18 | Philip` | is surprised Dreamhost is letting the process live for that long |
| 01:19 | <Hixie> | there's no process killing in private virtual servers |
| 01:19 | <Hixie> | 55 seconds |
| 01:19 | <Hixie> | ok this is clearly not faster :-) |
| 01:22 | <Hixie> | uh |
| 01:22 | <Hixie> | there are validation errors in the output |
| 01:22 | <Hixie> | http://html5.validator.nu/?doc=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2F.w3c-new%2FOverview.html&submit=Check |
| 01:23 | <Hixie> | (that's for the one generated by header-w3c + source) |
| 07:59 | annevk | wonders why it is suddenly a lot slower :/ |
| 08:32 | <annevk> | http://forums.java.net/jive/thread.jspa?threadID=47204 |
| 08:35 | <annevk> | http://www.webdirections.org/blog/session-spotlight-html5-with-michael-tm-smith/ heh, MikeSmith convinced those guys his real name is Michael (TM) Smith :p |
| 08:35 | <MikeSmith> | heh |
| 08:57 | <zcorpan_> | hsivonen: i wonder if it would be more useful than it is now to be fatal upon seeing a stray <tr> |
| 08:58 | <zcorpan_> | hmm hsivonen isn't here |
| 08:58 | <annevk> | is WebKit XBL2 dead? http://trac.webkit.org/log/branches/XBL2 |
| 08:59 | zcorpan_ | hopes hsivonen will read the logs |
| 08:59 | <zcorpan_> | hsivonen: maybe it would be useful to analyse logs where there were >1000 messages |
| 08:59 | annevk | was hoping that about zcorpan_ too, but doesn't remember what it was about again |
| 09:00 | <zcorpan_> | annevk: i did |
| 09:00 | <zcorpan_> | though i also don't remember what it was :) |
| 09:00 | <zcorpan_> | hsivonen: and identify cases where it's unhelpful to continue validation |
| 09:02 | <zcorpan_> | annevk: it was about dom core right |
| 09:02 | <annevk> | could be |
| 09:02 | <annevk> | likely even |
| 09:03 | <annevk> | any progress on that lately? |
| 09:03 | <zcorpan_> | no i've been busy with testing |
| 09:04 | <zcorpan_> | but maybe i can continue today |
| 09:05 | <MikeSmith> | annevk: I think Julien Chaffraix has been doing work on XBL2 - http://trac.webkit.org/search?q=jchaffraix |
| 09:05 | <zcorpan_> | hsivonen: another candidate is missing </ol> ("X not allowed as child of element ol in this context.") |
| 09:06 | MikeSmith | now looks at annevk URL |
| 09:07 | <zcorpan_> | annevk: i get FAIL (generator.process() failed) on web-dom-core |
| 09:09 | <annevk> | that means there's some kind of error in your markup |
| 09:09 | <annevk> | (I know that this is not helpful) |
| 09:10 | <zcorpan_> | annevk: do i need a charset meta? |
| 09:10 | <annevk> | no |
| 09:11 | <zcorpan_> | .html extension? |
| 09:11 | <annevk> | http://anolis.quuz.org/?url=http://simon.html5.org/specs/web-dom-core |
| 09:11 | <annevk> | it now gives some error information |
| 09:11 | <annevk> | seems you have a duplicate <dfn> |
| 09:11 | <zcorpan_> | hmm |
| 09:12 | <annevk> | i'll try to figure out how to give even more info :) |
| 09:14 | <annevk> | I probably need gsnedders for better integration but I'm guessing he's at school |
| 09:15 | <zcorpan_> | i don't see any duplicate terms :S |
| 09:16 | <annevk> | I need to figure out how I get the exception message |
| 09:16 | <annevk> | then it should tell you |
| 09:16 | <annevk> | i'm quite the Python noob |
| 09:21 | zcorpan_ | tests with bert's script |
| 09:21 | <zcorpan_> | hmm annoying that <i> and <var> are xreffed |
| 09:22 | <zcorpan_> | or maybe i'm misusing <i> |
| 09:23 | <zcorpan_> | aha |
| 09:24 | <zcorpan_> | i had createElement twice |
| 09:31 | <annevk> | i managed to figure out how to display a message for that now |
| 09:31 | <annevk> | see e.g. http://anolis.quuz.org/?url=http://www.whatwg.org/specs/web-forms/current-work/source |
| 09:31 | <zcorpan_> | Hixie: perhaps there should only be a hand cursor on <dfn>s if the dfn script has run |
| 09:31 | <zcorpan_> | annevk: nice |
| 09:32 | <annevk> | ah, http://anolis.quuz.org/?url=http://simon.html5.org/specs/web-dom-core is much more readable :) |
| 09:43 | <bfrohs> | Was there ever a pseudo-element created for definition list grouping? (see http://forums.whatwg.org/viewtopic.php?t=47) |
| 09:44 | <zcorpan_> | don't think so but you could push it on www-style or bug your browser vendor :) |
| 09:45 | annevk | isn't sure it's worth the added complexity |
| 09:52 | <Hixie> | zcorpan_: i did one better, it'll just be slow now if it's not ready yet, but it'll eventually show it |
| 09:55 | <annevk> | ooh, wget -r is nice |
| 09:57 | <jgraham> | annevk: You should put the source online somewhere |
| 09:57 | <annevk> | will a snapshot do for now? |
| 09:59 | <jgraham> | annevk: Sure; I'm mainly thinking it makes it easier if e.g. you need to ask gsnedders for debuging help |
| 09:59 | <annevk> | http://anolis.quuz.org/source |
| 10:00 | <zcorpan_> | Hixie: assuming that scripting is enabled or the script is referenced |
| 10:00 | <Hixie> | true |
| 10:01 | <zcorpan_> | s/or/and/ |
| 10:01 | <Hixie> | ok done |
| 10:02 | <bfrohs> | Oh, regarding my last comment about definition lists. I thought about it and it may actually be better to group them as discussed in the previously mentioned thread. |
| 10:02 | <zcorpan_> | thanks |
| 10:02 | <bfrohs> | The reason for this is because of :last-child, :first-child, etc |
| 10:03 | <bfrohs> | Currently, it'll do the last definition in the definition list.. not the last for the definition. |
| 10:03 | <bfrohs> | This makes it a structure error rather than styling. |
| 10:04 | <bfrohs> | Uses: Multiple definitions for the same term/phrase |
| 10:04 | <bfrohs> | And it can't currently be styled without 'hacks' |
| 10:05 | <annevk> | jgraham, gsnedders, Philip`, if you stot anything silly, let me know |
| 10:08 | <bfrohs> | http://dev.ravenleague.com/bones.php - see red line at the bottom of the dl... should be two red lines, not one (if it was grouped that is) |
| 10:10 | <annevk> | s/5px solid/15px double/ ? |
| 10:10 | <annevk> | :p |
| 10:12 | <bfrohs> | But if you have a border around the 2nd level dl, then you won't be able to use double border to separate it correctly. |
| 10:13 | <bfrohs> | And by two borders, there should be one under description of cf_connect and cf_timer_stop |
| 10:14 | <bfrohs> | The only way to do this currently is to make each one it's own definition list (add </dl><dl> before EVERY <td>) |
| 10:14 | <bfrohs> | <dt>* |
| 10:18 | <Hixie> | jesus there's totally no interop on this nonsense |
| 10:18 | <Hixie> | (setting .type dynamically, setting .defaultValue dynamically, etc) |
| 10:24 | <annevk> | despite non interop not being the best thing, it has created an entire market place for browser patching libraries... but then it's questionable whether all that effort is not better directed at something else |
| 10:26 | <annevk> | the IDs Anolis generates are wonderful |
| 10:50 | <annevk> | dominating: http://www.w3.org/2001/tag/2008/09/f2fkc-agenda |
| 10:57 | <Lachy> | "Given CSS and JavaScript, HTML can be reduced to _div_ and _span_." -- http://www.w3.org/2001/tag/2008/09/f2fkc-agenda#html5Embedding |
| 10:57 | <Lachy> | that's not entirely true. |
| 10:58 | <Lachy> | in fact, it's not true at all |
| 10:59 | <Lachy> | but what they fail to realise in their comparison is that random XML in a namespace is effectively no more semantic than <span class="">, within a browser that doesn't understand the vocabulary |
| 10:59 | <Hixie> | wow |
| 11:00 | <Hixie> | html5 is so successful the tag is spending almost half their meeting discussing html5 topics |
| 11:01 | <Lachy> | sure, if your measure of success is directly proportional to the length of time spent being discussed in a TAG meeting |
| 11:01 | <Hixie> | the tag discusses what they think is important |
| 11:02 | <Hixie> | what they think is important is directly related to where they perceive power exists |
| 11:02 | <Hixie> | success is power |
| 11:02 | <Lachy> | fair enough |
| 11:02 | <Hixie> | i'm amused by "3.4.2 Issue: HTML5 Should Be Modularized?" |
| 11:03 | <bfrohs> | Would it be possible to move html5 in a direction where it could use xml + namespaces in the future? |
| 11:03 | <Hixie> | is anyone arguing that html5 _shouldn't_ be "modularised"? |
| 11:03 | <bfrohs> | That way, sometime far into the future browsers will start using namespaces? |
| 11:03 | <bfrohs> | Then it will be semantic |
| 11:04 | <Hixie> | maybe they mean something different by "modularized" than i understand; i assume they mean splitting it up into different subspecs with new editors |
| 11:04 | <Hixie> | bfrohs: html5 already uses xml + namespaces |
| 11:04 | <Lachy> | it's interesting that the spec is already roughly divided into those kind of modules. It's just they they all exist in the same document |
| 11:04 | <Hixie> | bfrohs: and browsers (other than IE) already support it |
| 11:04 | <hsivonen> | Hixie: I hope there'd still be a single-page version of the subspecs |
| 11:05 | annevk | wonders how semantic is related to namespaces (or XML) |
| 11:05 | <bfrohs> | Has IE made any comments about it? Last I knew they were waiting until the spec was finished or something. |
| 11:05 | <Hixie> | Lachy: well the split they suggest is naive in the extreme, i mean, you can't split the parser from document.write and document.open, nor document.open from the navigation algorithm, nor the navigation algorithm from <a> and Window |
| 11:05 | <Hixie> | bfrohs: which spec? xml? |
| 11:06 | <bfrohs> | Well, XHTML in general. application+xhtml - a little unrelated but I'm sure you could give an answer quicker than me searching for it |
| 11:07 | <Hixie> | i don't know what microsoft's plans are |
| 11:07 | <Hixie> | "3.4.3 URL Parsing In HTML5" is funny too -- "This necessarily introduces aspects of the overall HTML5 parsing, and might over time lead to HTML5 error behavior bleeding into the rest of the Web that is more than just browsers." |
| 11:07 | <Hixie> | "might"? |
| 11:07 | <Hixie> | didn't we get there about 15 years ago? |
| 11:07 | <annevk> | wow, Python is slow, having a frontpage just being written out by a Python script already adds a few seconds to loading time |
| 11:08 | <annevk> | Hixie, for the TAG they don't see to understand much of how things actually work :/ |
| 11:09 | <Hixie> | no kidding |
| 11:09 | <Lachy> | is anyone from the HTMLWG going to be attending the TAG meeting? |
| 11:09 | <Philip`> | annevk: It's probably mainly CGI that is slow |
| 11:10 | <Hixie> | DanC and TV are in both the TAG and the HTMLWG, i think |
| 11:11 | <Philip`> | annevk: FastCGI or mod_python would presumably be much better, since they avoid the process startup overhead |
| 11:12 | <annevk> | thanks Philip`, looking into that now |
| 11:14 | <bfrohs> | Any insight into http://forums.whatwg.org/viewtopic.php?p=965#965 ? |
| 11:14 | <bfrohs> | Example (with a little more styles) - http://dev.ravenleague.com/bones.php |
| 11:15 | <Hixie> | dt + dd { ... } |
| 11:15 | <Hixie> | er |
| 11:15 | <Hixie> | dd + dt { ... } |
| 11:15 | <Hixie> | and use border-top instead of border-bottom |
| 11:16 | <Hixie> | in the general case though, css should be upgraded to handle things like that much better |
| 11:17 | <bfrohs> | But it isn't CSS's problem that the code wasn't made well. It's like... <section><h1>title</h1><p>text</p><p>text</p></section> |
| 11:17 | <bfrohs> | (I believe section is the correct tag in html 5) |
| 11:17 | <bfrohs> | We added it there, so why not in definition lists where it makes more sense? |
| 11:17 | <Hixie> | the code was made fine |
| 11:17 | <Hixie> | it's css problem that it can't handle the code |
| 11:18 | <Hixie> | <section> was added to allow simpler copy-and-paste of entire sections into nested sections without having to renumber <hx> elements |
| 11:18 | <Hixie> | there's no such problem with <dl> |
| 11:18 | <bfrohs> | So you're saying dd:last *should* apply to the last dd in each definition term section? |
| 11:18 | <Hixie> | in particular, <section> wasn't added for css at all |
| 11:18 | <Hixie> | no |
| 11:19 | <Hixie> | i'm saying you should use "dd + dt { border-top: ... }" to get the effect you want |
| 11:19 | <annevk> | hmm, http://wiki.dreamhost.com/Python_FastCGI |
| 11:19 | <bfrohs> | Yes, but what if we want to add something to the last dd that can't apply to the dt. |
| 11:20 | <bfrohs> | The way to do it now is to insert extra dd tags or separate each definition section into it's own dl |
| 11:20 | <annevk> | Philip`, I guess FastCGI wouldn't speed up the spec generation process? |
| 11:21 | <Hixie> | bfrohs: like i said, for the general case, css needs fixing |
| 11:22 | <Hixie> | bfrohs: how would you put a border around groups of <li> elements in a <ul> that have class="foo"? css can't do that either. |
| 11:23 | <bfrohs> | But whatwg is about improving the web right? The argument before was there was no need for this because it didn't add anything. But now I've brought forward an argument that shows it does add something and you're just dismissing it by claiming it's the fault of CSS when it would work perfectly fine just with the new tag? (current spec - :last-child, :first-child, etc do not work because of... |
| 11:23 | <bfrohs> | ...the code, not the css) |
| 11:23 | <Hixie> | bfrohs: whatwg is about improving html. not about working around limitations of css. |
| 11:23 | <Hixie> | bfrohs: to fix limitations of css, we should just fix css. |
| 11:23 | <Philip`> | annevk: No - it would just avoid having to launch Python and load all the imported modules every time you made a request |
| 11:24 | <annevk> | I guess that does help a bit |
| 11:24 | <Philip`> | annevk: Also it would introduce more admin complexity and possible points of failure :-) |
| 11:26 | <bfrohs> | Hixie: But the 'class=foo' argument doesn't apply to this. Definition lists are often grouped by term>definitions, yet there is no code to show this. There is no tag to say 'hey, these are grouped'. That is the point of a definition list. Unordered lists are just that - unordered. If you want to group them, simply make separate ones or insert them into definition lists (now that makes... |
| 11:26 | <bfrohs> | ...sense). But definition lists are meant to be grouped. |
| 11:26 | <Hixie> | definition lists _are_ grouped |
| 11:26 | <Hixie> | <dt> starts the group, and <dd> ends the group |
| 11:27 | <Hixie> | how about a group of adjacent rows all in the same <tbody>? |
| 11:28 | <Hixie> | css can't style those either |
| 11:28 | <bfrohs> | But there are multiple definitions to a single term sometimes. The current spec disables CSS's :last-child, :first-child, etc... so wouldn't this make it an error on HTML's side and not CSS's? |
| 11:28 | <bfrohs> | Tables are grouped by tables |
| 11:28 | <bfrohs> | That's why they have ONE header |
| 11:28 | <bfrohs> | If you want a new header, you make a new table |
| 11:28 | <bfrohs> | Definition lists are meant to display multiple definition terms and definitions. |
| 11:29 | <Hixie> | if you have a long table and you want to give a group of adjacent rows a particular style, e.g. a background that spans them all, there's no way to do that in css today |
| 11:29 | <Hixie> | it's exactly the same problem |
| 11:29 | <Hixie> | the groups are well-defined in something like <dl> <dt><dt><dd><dd><dd> <dt><dd><dd> <dt><dt><dt><dd> </dl> |
| 11:29 | <Hixie> | we don't need more markup to show them |
| 11:29 | <Hixie> | they are already unambgiuous |
| 11:30 | <Hixie> | unambiguous even |
| 11:30 | <bfrohs> | But there is no use to group rows in a table - they have the ability to switch back and forth if I'm correct |
| 11:30 | <bfrohs> | which is the only use I've ever seen in tables |
| 11:30 | <Hixie> | the spec doesn't disable CSS pseudo-classes, it's just that the CSS pseudo-classes don't do what you want here |
| 11:30 | <bfrohs> | Because dd:last-child should go to the last definition of a term |
| 11:30 | <bfrohs> | not the last definition of all the terms |
| 11:30 | <Hixie> | no it shouldn't |
| 11:31 | <Hixie> | it should go to the last child of its parent |
| 11:31 | <Hixie> | whatever that is |
| 11:31 | <bfrohs> | Exactly, so it's not the fault of CSS. It isn't doing what everyone expects it to do because the grouping isn't there when it should be. |
| 11:31 | <Hixie> | if you want a pseudo-class to match the last definition of a term, then ask the csswg to invent :last-definition-of-a-term or something |
| 11:32 | <Hixie> | the html is exposing all the semantics that you need to style this, it's css that isn't taking advantage of them |
| 11:32 | <Hixie> | it's just like how in css you can't style the third column of a table unless it has an explicit <col> element |
| 11:32 | <Hixie> | it's a limitation of css |
| 11:32 | <Hixie> | and it should be fixed |
| 11:33 | <bfrohs> | But that would be a waste of time on their part. If you came out with a new type of definition list, they'd have to do it all over again for that one. CSS shouldn't have to change because HTML is too lazy (or doesn't want) to add the grouping. |
| 11:33 | <bfrohs> | Yes, that I can see |
| 11:33 | <Hixie> | (and for all of these i proposed fixes years ago, i should point out) |
| 11:33 | <bfrohs> | But I still believe there should be more semantics for the definition list |
| 11:33 | <Hixie> | html shouldn't have to change because css is too lazy to add the expressiveness to handle basic html :-) |
| 11:33 | <Hixie> | adding a new element wouldn't add any semantics |
| 11:33 | <bfrohs> | Every designer I know wants it, but hasn't been able to come up with an argument you guys liked. |
| 11:33 | <Hixie> | the semantics are already all there |
| 11:34 | <Hixie> | why wouldn't you rather make css more powerful? |
| 11:34 | <bfrohs> | If you add the tag, :last-child and :first-child would work immediately |
| 11:34 | <bfrohs> | By not adding it, you're breaking CSS |
| 11:34 | <Hixie> | i've already explained why that isn't correct, though i understand that you don't necessarily agree |
| 11:34 | <Hixie> | but why wouldn't you rather make css more powerful? |
| 11:35 | <annevk> | by that argument CSS is broken, because <dl> came first (did it?) |
| 11:35 | <Hixie> | <dl> came first by several years |
| 11:35 | <bfrohs> | I've looked at it from both sides, I really have. And I'm looking at it from the outside so I don't have to work on implementing it. But from everything I've seen, this is the one solution that would make sense. |
| 11:35 | <bfrohs> | Yes, but just because something came first doesn't mean it's right. |
| 11:35 | <bfrohs> | "checked='checked'" for example |
| 11:35 | <bfrohs> | well, 'checked' |
| 11:36 | <bfrohs> | That leaves no room for forward-compatibility |
| 11:36 | <bfrohs> | We now see that with 'check all' boxes |
| 11:36 | <bfrohs> | There is no inbetween value |
| 11:36 | <Hixie> | i don't understand why you would rather fix just this one case instead of fixing all these cases all at once and making css much more powerful in the process |
| 11:36 | <bfrohs> | Because someone didn't see a use for it in the past. |
| 11:36 | <bfrohs> | But if CSS were to fix this, it would be ONE CASE |
| 11:36 | <bfrohs> | Not multiple |
| 11:36 | <bfrohs> | They already have the functionality for this.. it's just not grouped by HTML |
| 11:37 | <bfrohs> | Once again, :last-child and :first-child were made for this |
| 11:37 | <Hixie> | no, css could come up with a generic solution that applied to multiple rows, multiple <li>s in a group in a <ul>, multiple columns, all the examples i gave and many many more |
| 11:38 | <Hixie> | i've proposed various solutions to this kind of stuff over the past ten years, if the csswg wanted to fix it they could |
| 11:38 | <bfrohs> | And they could say the same for whatwg |
| 11:38 | <Hixie> | we couldn't do anything that fixed all those problems at once |
| 11:39 | <bfrohs> | No, but the obvious grouping is there, you said it yourself. But it would be easier to implement it in html than css |
| 11:39 | <bfrohs> | In over 6 years of experience, I have never had any other trouble with grouping except with definition lists |
| 11:40 | <Hixie> | you're lucky :-0 |
| 11:40 | <bfrohs> | I really don't see what's so hard about adding this tag that every designer I know of wants added |
| 11:40 | <Hixie> | adding the tag would be easy |
| 11:40 | <Hixie> | it's just the wrong solution |
| 11:41 | <bfrohs> | was thead and tbody the wrong solution? |
| 11:41 | <Hixie> | it doesn't add anything to the language, its entire purpose would be to work around a (temporary) limitation in another language |
| 11:41 | <bfrohs> | Here, I'll try one more example |
| 11:41 | <Hixie> | <thead>, <tbody> and <tfoot> aren't present for styling, they're present to indicate the parts of the table that are grouped together |
| 11:42 | <bfrohs> | Table - doesn't allow for more than one thead/tbody |
| 11:42 | <Hixie> | <table> can have multiple <tbody>s |
| 11:42 | <bfrohs> | but not multiple theads |
| 11:42 | <bfrohs> | so... |
| 11:42 | <bfrohs> | <div><table><thead><tr>...</tr></thead><tbody><tr>...</tr></tbody></table></div> |
| 11:42 | <bfrohs> | That is like a definition list |
| 11:43 | <zcorpan_> | bfrohs: a new tag doesn't work well in ie |
| 11:43 | <bfrohs> | Repeat the table to repeat the definition group |
| 11:43 | <bfrohs> | And IE needs an incentive to get up to standards |
| 11:43 | <bfrohs> | They're losing the market share daily - something like this will push the browser wars back into full action for IE |
| 11:43 | <zcorpan_> | bfrohs: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3Edocument.createElement('x')%3C%2Fscript%3E%3Cbody%3E%3Cdl%3E%3Cx%3E%3Cdt%3E%3Cdd%3E%3C%2Fdd%3E%3C%2Fx%3E%3Cx%3E%3Cdt%3E%3Cdd%3E%3C%2Fdd%3E%3C%2Fx%3E%3C%2Fdl%3E |
| 11:44 | <Hixie> | bfrohs: i don't see what the argument regarding multiple <table>s is supposed to show |
| 11:44 | <annevk> | bfrohs, oh come on |
| 11:44 | <bfrohs> | Tables have similar grouping to Definition Lists... add in the div to replace the <dl> tag. Table is the group. |
| 11:45 | <Hixie> | bfrohs: so? |
| 11:45 | <bfrohs> | thead is dt and tbodys are the dd |
| 11:45 | <annevk> | <dl> is already implicitly grouped |
| 11:45 | <Hixie> | bfrohs: you could say the same about <section><h1></h1><p><p></section><section><h1></h1><p><p></section><section><h1></h1><p><p></section> |
| 11:45 | <annevk> | for <table> you need <thead> is it not just the first row or something, it could be the first three rows |
| 11:46 | <Hixie> | bfrohs: the point is that with <dt> and <dd>, we don't need additional elements because the grouping is unambiguous |
| 11:46 | <zcorpan_> | bfrohs: you're giving Hixie a reason to not work on integrating <input> in html5 :P |
| 11:46 | <Hixie> | bfrohs: whereas with <tr><tr><tr> you have no way to know where the <thead> ends and the <tbody> begins |
| 11:47 | <bfrohs> | Well, I guess my major concern is :last-child and :first-child being broken. It works for tables with thead and tbodys |
| 11:48 | annevk | is reminded of http://twitter.com/gsnedders/statuses/923871883 |
| 11:48 | <bfrohs> | I don't see why it is CSS's fault if they have a system in place to fix this, yet it doesn't work because whatwg won't put in the tag. |
| 11:48 | <Hixie> | bfrohs: no it doesn't |
| 11:48 | <bfrohs> | okay, well it works with sections and ps |
| 11:48 | <Hixie> | bfrohs: no it doesn't |
| 11:49 | <Hixie> | bfrohs: in <section><h1></h1><p>... p:first-child doesn't match anything |
| 11:49 | <bfrohs> | How doesn't it work for p tags? |
| 11:49 | <zcorpan_> | and so they added :first-of-type |
| 11:49 | <Hixie> | and in <h1></h1><p><h1></h1><p> p:first-of-type doesn't match the first paragraph of the second section |
| 11:49 | <zcorpan_> | h1+p |
| 11:50 | <Hixie> | dt + dd |
| 11:50 | <zcorpan_> | yes |
| 11:50 | <Philip`> | dd.lastrow { ... } |
| 11:50 | <annevk> | well, <h1></h1><img><p> too |
| 11:50 | <zcorpan_> | h1 + img + p |
| 11:50 | <zcorpan_> | :P |
| 11:51 | <zcorpan_> | or what Philip` said |
| 11:51 | <annevk> | h1 + video + p, h1 + embed + p, h1 + svg + p, etc. |
| 11:51 | <zcorpan_> | h1 + :not(p) + p |
| 11:51 | <bfrohs> | Okay, well, the one thing I want does work with h1 + p - :last-child |
| 11:51 | <Hixie> | h1 ~ p:not(:matches(p + #)) ? :-) |
| 11:51 | <annevk> | zcorpan_, fails if some <p>s are grouped in a section |
| 11:52 | <annevk> | s/section/<div> |
| 11:52 | <Hixie> | bfrohs: doesn't match the first <p> in the example above |
| 11:52 | <bfrohs> | But p:last-child works |
| 11:53 | <annevk> | only if there's no img at the end |
| 11:53 | <Philip`> | <script>for each (var p in document.getElementsByTagName('p')) if (arbitraryExpression(p)) p.className += ' first-paragraph'</script> |
| 11:53 | <Hixie> | bfrohs: so does dd:last-child -- your definition of "works" is wrong. :-) |
| 11:53 | zcorpan_ | needs to go back to work |
| 11:53 | <bfrohs> | Works how people want it to. |
| 11:53 | <bfrohs> | Before <section> we used <div> |
| 11:54 | <Hixie> | well, get the css wg to fix css to handle this case too |
| 11:54 | <bfrohs> | Okay, I give up haha |
| 11:55 | <bfrohs> | Are ordered lists still using 'reversed' as the attribute? |
| 11:55 | <bfrohs> | rather than 'order' or something that makes more sense? |
| 11:55 | <Hixie> | yes |
| 11:55 | <bfrohs> | *refer to my checked example from earlier* |
| 11:56 | <bfrohs> | Why aren't we using 'order' instead? |
| 11:56 | <bfrohs> | What if another order option comes up in the future that we didn't see coming (like 'checked') |
| 11:56 | <Hixie> | kiss principle |
| 11:57 | <Hixie> | we can always add an order="" attribute |
| 11:57 | <Hixie> | reversed isn't the ordering |
| 11:57 | <Hixie> | it's just the decision of whether to put things backwards or forwards |
| 11:57 | <bfrohs> | Kiss principle is what made it so we only have 'checked' and 'not checked' |
| 11:57 | <bfrohs> | Even though there's the 'check all' box with 'some are checked' value |
| 11:58 | Philip` | likes it when boolean attributes are guaranteed to not grow a third state in the future |
| 11:58 | <annevk> | bfrohs, we can always add a new attribute if there really is a need |
| 11:59 | <Hixie> | bfrohs: tristate checkboxes are something we've looked at introducing, but so far we've decided not to. however, the checked attribute doesn't stop us from adding a third state using another attribute. |
| 11:59 | <bfrohs> | But we're so worried about backward-compatibility that no one is thinking about forward-compatibility |
| 11:59 | <annevk> | euhm? |
| 11:59 | <bfrohs> | If we make it 'order' now, we won't have to worry about 'is this going to break a browser if we add it' or anything of that nature |
| 12:00 | <Hixie> | yes we will |
| 12:00 | <Hixie> | because someone will say order="foo" |
| 12:00 | <Hixie> | even though it's not valid |
| 12:00 | <Hixie> | and so we'll have to make sure that we don't introduce a value order="foo" because it would break pages that (incorrectly) used it |
| 12:03 | <Lachy> | Hixie, are tristate checkboxes being postponed till WF3? |
| 12:03 | <Hixie> | dunno |
| 12:03 | <Hixie> | depends what gets implemented |
| 12:04 | <hsivonen> | Postponing tristate checkboxes means more ARIA |
| 12:04 | <Lachy> | I suppose that makes sense, since there were questions about what exactly the use cases were and whether or not the intermediate value needs to be submited in some way |
| 12:04 | <Lachy> | and how to submit it if needed |
| 12:04 | <Hixie> | i haven't really considered it, i'm just not adding features unless i have to until browsers get closer to having a lot of html5 done |
| 12:05 | <Hixie> | and i only have to when browser vendors are so hell bent on implementing something that they'll do it with or without a spec |
| 12:05 | <Hixie> | e.g. workers |
| 12:06 | <Lachy> | ok. If I have time I'll look into them and perhaps I can talk to someone about getting an experimental implementation in opera |
| 12:06 | <annevk> | hsivonen, there's a lot of other features from HTML5 browsers can add first that obsolete the need for parts of ARIA |
| 12:07 | <Hixie> | Lachy: i recommend focusing on already-specced things, we really have a lot to work with as it is |
| 12:07 | <annevk> | Lachy, if there's time I'd prefer we prioritize differently :) |
| 12:07 | <Lachy> | yeah, sure |
| 12:07 | <Hixie> | Lachy: the further the spec gets from where browsers are, the less likely we'll ever get interop |
| 12:08 | <Lachy> | I don't have time now, or in the near future |
| 12:08 | <Lachy> | I wanted placeholder well before tristate checkboxes anyway |
| 12:08 | <Lachy> | and there already is an implementation of that |
| 12:09 | <Hixie> | placeholder might make it |
| 12:09 | <Lachy> | :-) |
| 12:10 | <Hixie> | there's a lot of demand for it and as you say, implementations are implementing it already |
| 12:11 | <Lachy> | type=search and the associated api would be nice too |
| 12:12 | <Hixie> | less of a priority but yes |
| 12:15 | <Hixie> | ok bed time |
| 12:15 | <Hixie> | nn |
| 12:18 | <Lachy> | I need to write an abstract for a presentation I'm giving in 3 weeks, any suggestions for what topics I can cover? |
| 12:19 | <Lachy> | It can be on any standards stuff I work on, including HTML5 stuff or Selectors API or whatever |
| 12:20 | Lachy | checks the list of what is being implemented |
| 12:21 | <annevk> | people like <canvas> demos |
| 12:22 | <Lachy> | ok, I can reuse the ones I used at @media |
| 12:22 | <MikeSmith> | CSS transforms |
| 12:22 | <annevk> | e.g. Super Mario & Large Hadron Collider from http://nihilogic.dk/ |
| 12:22 | <Lachy> | thanks |
| 12:23 | <Lachy> | MikeSmith, is that the webkit extensions? |
| 12:23 | <MikeSmith> | Lachy: yeah, Gecko has some support for them now too |
| 12:23 | <Lachy> | with -moz- prefixes? |
| 12:23 | <MikeSmith> | I think roc blogged about it a few days back |
| 12:23 | <MikeSmith> | dunno |
| 12:23 | Philip` | always imagines the LHC curving in the other direction |
| 12:23 | MikeSmith | goes to look for blog post |
| 12:23 | <Lachy> | do you have a link? |
| 12:24 | <MikeSmith> | http://developer.mozilla.org/web-tech/2008/09/12/css-transforms/ |
| 12:26 | <MikeSmith> | also http://weblogs.mozillazine.org/roc/archives/2008/09/css_transforms.html |
| 12:26 | <virtuelv> | annevk: or one of p01's canvas demos |
| 12:27 | <MikeSmith> | p01 favicon thing |
| 12:27 | <Lachy> | I should use that canvas favicon demo :-) |
| 12:27 | <Lachy> | year |
| 12:27 | <annevk> | yeah, he has some fun games too |
| 12:27 | <Lachy> | yeah |
| 12:28 | <annevk> | http://blog.whatwg.org/this-week-in-html-5-episode-5#comment-27308 |
| 12:28 | <MikeSmith> | would be great to cover ARIA but I guess that's not the easiest thing to demo |
| 12:28 | <annevk> | it's quite easily explained though |
| 12:28 | <MikeSmith> | aye |
| 12:29 | <MikeSmith> | can talk about e.g. Google apps that have already added support for it |
| 12:29 | <virtuelv> | Lachy: p01 also has an awesome four panels thing |
| 12:29 | <Lachy> | virtuelv, yeah, I have a copy of that 4 panel thing already |
| 12:29 | <Lachy> | that's the one I used at @media |
| 12:29 | <Lachy> | I also used Philip`s canvex demo |
| 12:31 | <Lachy> | virtuelv, where can I find p01's demos? |
| 12:31 | <virtuelv> | www.p01.org |
| 12:32 | <virtuelv> | Lachy: there are also plenty of stuff to be found here: http://www.ozoneasylum.com/7808 |
| 12:33 | <virtuelv> | this one is pretty awesome |
| 12:33 | <virtuelv> | http://www.p01.org/releases/DHTML_contests/files/20lines_hypno_trip_down_the_fractal_rug/ |
| 12:35 | <Lachy> | I can't find that favicon demo |
| 12:35 | <virtuelv> | http://www.p01.org/releases/DHTML_contests/files/DEFENDER_of_the_favicon/ |
| 12:37 | <hasather_> | Lachy: go and ask p01 if you can see his unreleased demos, you will be blown away |
| 12:48 | <Lachy> | ok, I'm going to make the presentation a show case of new and upcoming standards that are being implemented. |
| 12:48 | <Lachy> | This is what I have on my list so far: canvas demos, video and audio demos, CSS transforms and animations, getElementsByClassName, Selectors API, some Web Forms 2 controls, and an introduction to Web Workers |
| 12:49 | <Lachy> | that seems like reasonable coverage of HTML, CSS and JavaScript stuff |
| 13:00 | <MikeSmith> | Lachy: who's the audience? |
| 13:22 | Philip` | imagines most canvas demos are totally irrelevant to most audiences |
| 13:22 | <Philip`> | Graphs are kind of useful, though |
| 13:24 | <annevk> | (the audience I had mostly does JavaScript for a living) |
| 13:40 | <Philip`> | Re http://blog.whatwg.org/this-week-in-html-5-episode-5#comment-27295 : I thought IE did something like just strip the 8th bit off us-ascii content, instead of treating it like windows-1252? |
| 13:51 | <hsivonen> | Philip`: that's my hearsay recollection. Perhaps worth your comment on the blog? |
| 13:57 | <Philip`> | hsivonen: I'd prefer not to spread hearsay, and I'm too lazy/busy to test it or look it up and get a more reliable answer |
| 14:01 | <jcranmer> | oh, fun, it looks like my CS teacher is trying to do a stack example with HTML... |
| 14:05 | <Lachy> | MikeSmith, it's for a web standards group meeting, which is predominately web developers and designers |
| 14:05 | <billyjack> | Lachy: I see |
| 14:07 | <Philip`> | Lachy: I presume you'll be saying stuff about what features they can use now and won't have to wait until 2022 for? |
| 14:07 | <Lachy> | Philip`, yes, that's the point of focussing on stuff that they can use now or in the near future |
| 14:11 | <billyjack> | Lachy: I'd be interested in seeing what you come up with for the part about Workers. |
| 14:11 | <billyjack> | Seems like one common way to introduce concepts around something new like Workers is to compare it something the audience might already be familiar with |
| 14:11 | <billyjack> | but the only thing I can think of to compare workers to is message passing in Erlan |
| 14:11 | <billyjack> | Erlang |
| 14:12 | <billyjack> | which I guess is something most audiences are probably not going to be terrifically familar with |
| 14:12 | <Philip`> | That isn't quite the only place in the world where message passing is used |
| 14:12 | <Lachy> | I'll probably show a slide with a photo of a lazy council worker and write some bullet points |
| 14:12 | <Philip`> | What you need is a car analogy |
| 14:12 | <Lachy> | I know nothing about cars |
| 14:13 | <Lachy> | and I assume most web developers and designers wouldn't know much about them either |
| 14:13 | <Philip`> | Compare it to asynchronous XHR, except with the X or H or R and without a remote server |
| 14:14 | <annevk> | compare it with a single lane one way versus a double lane one way versus a triple lane one way, etc. |
| 14:15 | <Lachy> | yeah, something like that could work |
| 14:16 | <Lachy> | maybe a diagram illustrating how things executing in a single thead is slower compared with multiple independent threads that notify you when they're done |
| 14:16 | <jgraham> | Car anaology: The main thread is like the driver, it is the only one with access to the controls (UI). workers are like passengers, the driver can ask them to do stuff like look at the map or listen to the radio for traffic information and can then change the route based on what they say, but they have no direct access to the controls :) |
| 14:17 | <Philip`> | Point out how terrible it is that a page loaded with ugly animated adverts and pointless complex AJAX can only use 25% of your shiny new quad-core CPU, and wouldn't it be so much better if it could use 100% |
| 14:17 | <jgraham> | obviously map == database and radio == XHR |
| 14:17 | <annevk> | jgraham, that's a nice one |
| 14:18 | <Lachy> | yeah, of course, that's exactly what end users want: web pages that make their computers constantly use 100% of their processor |
| 14:18 | <Philip`> | Sure - that's why we're adding support for multithreaded computation |
| 14:19 | <Philip`> | And think how much faster raytracers written in JS could go, which will usher in a new era of useless tech demos |
| 14:21 | <billyjack> | I think it would be cool if you went through the whole car analogy or multi-lane analogy, and then at the end somebody raises his hand and says, "This is sort of uncanny, but your analogies make these Worker things sound a lot like message passing in say, a language like Erlang." |
| 14:27 | <Philip`> | Doing computation in workers seems a bit silly, since nobody really does that much computation (particularly since it needs a lot of computation on little data, to make the message-passing overhead worthwhile) - synchronous database/network operations sound a much more useful issue |
| 14:29 | <Philip`> | Hixie: In web-workers: "The worker then just listens for messages from the worker and acts on them as appropriate" - second "worker" should probably be "server" |
| 14:29 | <zcorpan_> | hsivonen: tristate checkboxes were dropped from aria iirc |
| 14:29 | <Philip`> | Hixie: Also s/backgroud/background/ |
| 14:41 | <hsivonen> | zcorpan_: Ah. I had either missed that or had forgotten |
| 14:51 | <zcorpan_> | i think it was about a year ago |
| 14:57 | <Lachy> | how does this sound for an abstract: |
| 14:57 | <Lachy> | What’s New in Web Standards |
| 14:57 | <Lachy> | An overview of the new and upcoming web standards that are being implemented in current or upcoming releases of browsers. This presentation will show case a range of new features in HTML, CSS and the DOM that will be usable in the near future. |
| 14:58 | <Lachy> | (I want to leave it a little broad, rather than listing specifics, because the presentation isn't yet written and some things may be added or dropped between now and then) |
| 14:59 | <billyjack> | Lachy: needs more cowbell |
| 14:59 | <Lachy> | explain |
| 15:00 | <billyjack> | more cowbell, man .. bang the cowbell more aggressively |
| 15:01 | <billyjack> | title: Is there really any hope left at all for Web standards? |
| 15:01 | <Lachy> | http://en.wikipedia.org/wiki/More_cowbell |
| 15:01 | <Lachy> | it's an american thing. |
| 15:02 | <billyjack> | America plus Alaska |
| 15:02 | Lachy | attempts to translate to Aussie slang |
| 15:03 | <billyjack> | title: Should we give up on Web standards completely? |
| 15:03 | <billyjack> | title: Do Web standards needs more cowbell? |
| 15:05 | <Lachy> | I'm still trying to work out how to translate that description of the more cowbell skit into something meaningful |
| 15:05 | <Lachy> | that applies to my abstract |
| 15:10 | Philip` | finds it odd that an ISO standard defines "hippity" |
| 15:11 | <Philip`> | ("HIPPITY – Bit 3 – A value of 0 indicates zero hippity cost, and a value of 1 indicates infinite hippity |
| 15:11 | <Philip`> | cost." etc) |
| 15:11 | Philip` | has no idea why they use that term |
| 15:13 | <hsivonen> | Lachy: the abstract as written above is a bit generic. you need to pitch something more unique or something more controversial |
| 15:13 | <Lachy> | heh, that's what Marcos told me :-) |
| 15:13 | Lachy | goes to think about it... |
| 15:14 | <billyjack> | controversy is always good, even if you have to invent it |
| 15:14 | hsivonen | wishes Java classloaders were less picky about resource naming |
| 15:15 | <Philip`> | billyjack: i.e. trolling? |
| 15:16 | <billyjack> | Philip`: well, no, trolling is bad |
| 15:16 | <billyjack> | I mean as far as session descriptions go |
| 15:17 | <billyjack> | most session descriptions for events are so deadly boring that it's hard to work up much motivation to take any interest |
| 15:18 | <Lachy> | How about "The New Cool Stuff We've Got, All Without Distributed Extensibility or RDF" |
| 15:18 | <Philip`> | Do people go to sessions because they want to learn something, or do they go because they think the speaker sounds entertaining? |
| 15:18 | <Lachy> | I think they go to the WSG meetings for the free beer |
| 15:18 | <hsivonen> | Philip`: the latter |
| 15:19 | <zcorpan_> | Lachy: that's only controversial on www-tag :P |
| 15:20 | <Philip`> | Lachy: That would probably be meaningless to people who weren't already part of the HTML5 gang and knew about the animosity towards distributed extensibility and RDF |
| 15:21 | <Lachy> | ok, well, I obviously suck at coming up with controversial titles. Any suggestions? |
| 15:21 | <Philip`> | You should call it "Your web sites are boring and ugly: We'll give you shiny things" |
| 15:22 | <Lachy> | it's a bit long |
| 15:22 | <Lachy> | Shiny New Things for Your Web Site? |
| 15:22 | <Lachy> | s/Shiny New/New Shiny/ |
| 15:22 | <Lachy> | or s/New// |
| 15:23 | <Philip`> | Just call it "Shiny!" |
| 15:24 | <Lachy> | if I called it that, it would need a good abstract to explain it |
| 15:25 | <hsivonen> | "Anything good coming out of Web standards?" |
| 15:26 | <Philip`> | Your abstract could just be "Shiny shiny shiny!" |
| 15:26 | <Philip`> | Nobody could resist going along to see what it was about |
| 15:26 | <Lachy> | How about "Web 3.0" |
| 15:27 | <annevk> | boring |
| 15:27 | <Lachy> | see, I told you I suck at this :-) |
| 15:27 | <annevk> | hsivonen wins so far |
| 15:27 | <Lachy> | Shiny Stuff! |
| 15:27 | <Lachy> | New, shiny stuff is under development in web standards that are being implemented in current or upcoming browser releases. This presentation will showcase a range of new toys to play with in HTML, CSS and the DOM that you can start using to spice up your web app. |
| 15:28 | <Lachy> | hsivonen's title is good too |
| 15:28 | <annevk> | call it "Look ma, no Flash" or something |
| 15:29 | <Lachy> | Anything good coming out of Web standards? |
| 15:29 | <Lachy> | Yes! Come along and find out what. |
| 15:29 | <annevk> | standards scores high on being boring these days I think |
| 15:30 | <Lachy> | "Look What You Can Do Without Flash These Days" |
| 15:30 | <annevk> | too long |
| 15:30 | <Philip`> | Would normal web developers/designers be happy to be told they could stop using Flash and all its nice authoring tools and interoperability and everything, and should start writing loads of JS code in Notepad instead? |
| 15:31 | <annevk> | considering most still make HTML pages, yes |
| 15:31 | <Lachy> | the kind of people that go the the Web Standards Group meetings, where I'm presenting this, aren't really into Flash |
| 15:33 | <annevk> | then they might be happy to hear they don't have to use it anymore |
| 15:33 | <annevk> | :) |
| 15:34 | <Lachy> | Ok, I could go with "Look, No Flash" |
| 15:35 | <Philip`> | "Don't Flash Me" |
| 15:35 | <zcorpan_> | Look ma, no divs |
| 15:36 | <Philip`> | "Look, Upside Down Text, Isn't That Useful" |
| 15:37 | Philip` | wonders if there are better examples of the CSS Transform stuff |
| 15:38 | <zcorpan_> | ʇxǝʇ uʍop ǝpısdn ǝʇıɹʍ |
| 15:39 | <annevk> | zcorpan_, hmm, how? |
| 15:39 | <zcorpan_> | i use a special command in irc |
| 15:39 | <Lachy> | No Flash Allowed |
| 15:39 | <Lachy> | Web standards and browser are getting rapidly closing the gap between what is possible with Flash, and what is possible with web standards like HTML, CSS and JavaSript. New features are currently under development to to provide designers and developers with more flexibility for creating great looking, interactive and responsive web sites and applications. |
| 15:40 | <Lachy> | s/browser/browser vendors/ |
| 15:40 | <Lachy> | s/getting// |
| 15:40 | <Philip`> | zcorpan_: Sadly your text was defeated by my terminal's font's lack of glyphs :-( |
| 15:41 | <Lachy> | Web standards and browser vendors are rapidly closing the gap between what is possible with Flash, and what is possible with web standards like HTML, CSS and JavaSript. New features are currently under development to to provide designers and developers with more flexibility for creating great looking, interactive and responsive web sites and applications. This presentation will showcase the latest features that features that you can begin using now or |
| 15:41 | <Lachy> | in the near future. |
| 15:41 | <Philip`> | s/Sript/Script/ |
| 15:42 | <zcorpan_> | Philip`: sɥdʎlƃ ǝɹoɯ ɥʇıʍ sʇuoɟ llɐʇsuı os |
| 15:42 | Lachy | finds http://www.revfad.com/flip.html |
| 15:43 | <Lachy> | the abstract is good, but should I go with "No Flash Allowed", "No Flash Required", "No Flash", "Look, No Flash" or something else for the title? |
| 15:43 | zcorpan_ | used http://www.fliptext.info/index.php |
| 15:44 | <Philip`> | zcorpan_: I have such fonts installed, but not monospace ones |
| 15:44 | <zcorpan_> | Philip`: ok |
| 15:44 | <Philip`> | and I don't know how to configure fallback fonts in Linux anyway |
| 15:45 | <Philip`> | so I'll just put up with all the interesting characters being rendered as boxes |
| 15:48 | <Lachy> | I think I'm going to go with "Flashy Stuff, Without Flash" |
| 15:51 | <hendry> | http://lwn.net/Articles/298755/ # interesting 1.0 release of dirac video codec |
| 15:54 | <Philip`> | The problem with codecs like Theora and Dirac is that you can't compare them to e.g. MPEG-4 without it being an unfair comparison because Theora/Dirac encoders are rubbish compared to the state-of-the-art MPEG-4 encoders |
| 15:55 | <Lachy> | Philip`, is that a problem with the implementations, or with the algorithms they're using? |
| 15:56 | zcorpan_ | notes that Hixie made <legend> required in fieldset |
| 15:57 | <Philip`> | Lachy: Both, I expect - they could implement the algorithms better, and they could choose better algorithms to implement (while still outputting content that's compatible with any conforming decoder) |
| 15:58 | <Philip`> | (The specs only say how to decode the video, not how to encode it, so encoders can do whatever fancy tricks they can think of) |
| 15:59 | <Lachy> | oh, really? I thought they defined how to encode it as well |
| 16:00 | <Lachy> | but that might explain why there's DivX and Xvid are both implementations of MPEG4, and yet are somehow different |
| 16:00 | <annevk> | zcorpan_, I wasn't sure how to start complaining about it |
| 16:01 | annevk | wonders why <label> is allowed to be associated with nothing |
| 16:03 | <Philip`> | Lachy: http://www.theora.org/doc/Theora.pdf says "The Theora format is well-defined by its decode specification; any encoder that produces packets that are correctly decoded by an implementation following this specification may be considered a proper Theora encoder." |
| 16:03 | <Philip`> | "... Where appropriate, a non-normative description of encoder processes is included. These sections will be marked as such, and a proper Theora encoder is not bound to follow them." |
| 16:05 | <Philip`> | Hmm, I can only see about one bit describing the encoder process |
| 16:05 | <Philip`> | The rest is all just for decoders |
| 16:06 | <annevk> | gsnedders, Anolis in JavaScript? http://ajaxian.com/archives/aptana-jaxer-benchmarks |
| 16:07 | <Philip`> | That graph would be more meaningful if the bar colours were labelled |
| 16:08 | <annevk> | yeah, follow the link |
| 16:08 | <Philip`> | Oh, the image does have a legend, but it's cut off because it's wider than the content column |
| 16:17 | Philip` | has used wxJavaScript for adding GUI scriptability to a C++ application, but oddly that library has migrated towards being a server-side web scripting engine |
| 16:18 | <jgraham> | annevk: That just shows that Rails is slow, which isn't really news |
| 16:18 | <Philip`> | (The wx parts obviously don't work at all on a web server, but it has modules for io and sqlite and curl and stuff) |
| 16:20 | <annevk> | jgraham, it shows that JavaScript is competitive |
| 16:20 | <Philip`> | Does Jaxer have competitive functionality to Rails? |
| 16:22 | <annevk> | dunno |
| 16:22 | <annevk> | I meant in speed, not feature set |
| 16:23 | <Philip`> | It looks kind of like old-fashioned PHP where you embed all your code inside special tags in HTML files |
| 16:24 | Philip` | imagines it would be hard to find a language whose performance was not competitive with Ruby's |
| 16:27 | <annevk> | hmm ok |
| 16:28 | <Philip`> | Clearly all server-side web programming should be done in OCaml |
| 16:32 | <jgraham> | annevk: Ruby 1.8 is supposedly a factor of ~3 slower than Python so python would be close to PHP. OTOH, js+tracemonkey might be a big win |
| 16:34 | <Philip`> | But only if you're spending significant time in JS, rather than in API calls |
| 16:35 | <jgraham> | Philip`: Sure. Some of those benchmarks look pretty microbenchmarky to me |
| 16:35 | <jgraham> | The python jit thing which I have forgotten the name of sped up html5lib quite a bit |
| 16:35 | <jgraham> | psyco |
| 16:36 | <jgraham> | annevk: You could try installing psyco on DH but it will only work if their servers are 32 bit which seems unlikely |
| 16:37 | <gsnedders> | annevk: Can you give me an example of [STATUS] not being replaced? |
| 16:37 | <annevk> | meh, I've installed enough custom fu for now |
| 16:37 | <annevk> | gsnedders, it's because it's in an attribute value I found out |
| 16:37 | <gsnedders> | annevk: That should still be replaced |
| 16:37 | <annevk> | gsnedders, I made some notes: http://anolis.quuz.org/notes |
| 16:37 | <annevk> | gsnedders, your docs suggest otherwise |
| 16:38 | <Philip`> | jgraham: It should work if you've got 32-bit Python even if the servers are 64-bit |
| 16:38 | <gsnedders> | annevk: --w3c-compat-xref-a-placement — Hixie needs that :( |
| 16:38 | <annevk> | gsnedders, yes, I enabled it by default |
| 16:38 | <annevk> | gsnedders, I think you should just go with "compat" as default and kill the option... |
| 16:38 | <annevk> | gsnedders, http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.src.html is an example |
| 16:39 | <annevk> | gsnedders, though maybe the problem is that you're not picking a default of ED... |
| 16:40 | <jgraham> | Philip`: Good point. Although I guess annevk installed with the default bittiness which presumably matches the processor arch |
| 16:40 | <gsnedders> | annevk: w3c_compat_replacements needs to be set to True |
| 16:40 | <gsnedders> | annevk: That's the case because those replacements only make sense for W3C docs |
| 16:41 | <hober> | lots and lots of html5 in the tag f2f agenda |
| 16:48 | <gsnedders> | Hixie: The validation errors are only present in the lxml copy :P |
| 16:48 | <gsnedders> | http://html5.validator.nu/?=&doc=http%3A%2F%2Fstuff.gsnedders.com%2Fspec-gen%2Fhtml5.html |
| 16:49 | <gsnedders> | Yeah, libxml's serializer is b0rked |
| 16:50 | <gsnedders> | annevk: gsnedders: 'When xref'ing <code>foo</code>, should you get <a><code>foo</code></a> or <code><a>foo</a></code> — I assume the former because you are linking the term, and not the word "foo".' |
| 16:50 | <gsnedders> | annevk: Hixie: "That makes sense, yeah." |
| 16:52 | <Philip`> | jgraham: I could be pedantic and argue that the default bittiness probably matches the OS architecture rather than the actual processor architecture :-) |
| 16:53 | Philip` | has installed 32-bit Linux on a Core 2 because it seemed to have compatibility advantages and no real disadvantages (at least with only 2GB RAM) |
| 16:54 | <gsnedders> | jgraham: Yeah, I always knew the physics part would be weaker :) |
| 16:55 | <annevk> | gsnedders, well, changed my mind :) |
| 16:55 | <gsnedders> | annevk: Hixie just can't get the styling he wants with it :P |
| 16:57 | <annevk> | I guess it doesn't matter |
| 16:57 | <annevk> | anyway, I'm not planning on exposing the alternate version through the interface |
| 16:57 | <gsnedders> | annevk: I'd at least make the full w3c compat mode visible |
| 16:57 | <gsnedders> | (like w3c_compat=True) |
| 16:58 | <annevk> | maybe, have to figure out what's actually required |
| 16:59 | <gsnedders> | annevk: XHR will need it |
| 17:00 | gsnedders | wishes ID generation was simpler |
| 17:00 | <annevk> | gsnedders, it's a W3C doc, it's just an ED draft... |
| 17:00 | <annevk> | (re status) |
| 17:01 | <gsnedders> | annevk: None of the other statuses make sense for non-W3C docs though |
| 17:01 | <gsnedders> | annevk: And I have no means to know what status they are |
| 17:01 | <annevk> | why would non-W3C docs use [STATUS] etc.? |
| 17:01 | <gsnedders> | annevk: Besides, 1.0 is just the keeping Hixie mostly happy release |
| 17:01 | <gsnedders> | annevk: They shouldn't, therefore it shouldn't replaced. It's quite expensive to do the string replacements. |
| 17:02 | <jgraham> | gsnedders: The problem you have is that it sounds like you are actually interested in CS and, although you claim to be interested in physics it's not really clear if its true |
| 17:02 | <gsnedders> | jgraham: I suck at writing about physics :( |
| 17:03 | <jgraham> | Or if, for example, its' just that someone in your family told you to apply for physics because CS isn't manly enough or something (I guess that's not true but for some people it could be) |
| 17:03 | <Philip`> | gsnedders: You should express your interest by saying "I read a lot about the LHC and I think black holes are cool so I hope they find one" |
| 17:03 | <annevk> | gsnedders, hmm, it's annoying I need to flag it as W3C doc |
| 17:03 | <annevk> | gsnedders, can I set a flag to try replacements by default? |
| 17:04 | <annevk> | gsnedders, with ED as default? :) |
| 17:04 | <gsnedders> | annevk: Meh. There is no flag, I don't really want to add one. It's just expensive. |
| 17:06 | gsnedders | remembers the diff. being far more what he just got testing |
| 17:06 | <annevk> | I might be able to hack it in :) |
| 17:07 | <gsnedders> | annevk: Just finding the W3C status takes 0.520s in HTML 5 |
| 17:07 | <gsnedders> | (it fails to find any, needless to say) |
| 17:07 | <annevk> | you should be able to speed that up a bit |
| 17:08 | <gsnedders> | annevk: It needs to do a case-insensitive search in every text node |
| 17:08 | <annevk> | why not only check in the first <dl> on the page? |
| 17:09 | <gsnedders> | annevk: Docs rely on its current behaviour |
| 17:09 | <annevk> | i can't name one |
| 17:09 | <gsnedders> | CSSOM for example |
| 17:10 | <annevk> | CSSOM would set the status always within the first <dl> |
| 17:11 | <annevk> | http://dev.w3.org/csswg/cssom/Overview.src.html but it's not there, so it should default to ED |
| 17:11 | <gsnedders> | annevk: You have to be careful not to get the REC there |
| 17:11 | <annevk> | (status is derived from the "This version" link) |
| 17:11 | <gsnedders> | annevk: No, actually, it isn't |
| 17:11 | <annevk> | it should be |
| 17:12 | <gsnedders> | http://hg.gsnedders.com/anolis/raw-file/1.0RC1/README.html#w3c-status |
| 17:14 | <annevk> | I think you can speed that up along the lines I suggested and not break existing specs |
| 17:14 | <annevk> | (or they can easily be tweaked) |
| 17:14 | <annevk> | also, turning on W3C replacements can be done if there's a "this version" with w3.org in it |
| 17:15 | <Philip`> | You could use the doctype to trigger (in)compatibility mode |
| 17:15 | <annevk> | (btw, the service is quite a big improvement already, I just want to make it a little better) |
| 17:15 | <Philip`> | If it says <!doctype html> then it's written by a cool person and you don't need to bother with all the old compatibility hacks |
| 17:16 | <Philip`> | Also, rather than searching all the text nodes, can't you just run a regular expression over the input document string? |
| 17:24 | <billyjack> | hallvord's latest blog post is beautiful |
| 17:24 | <billyjack> | definitely prime WTF material |
| 17:29 | <Philip`> | "<xsl:text disable-output-escaping="yes"><</xsl:text>" - that doesn't look well-formed - is it just an error in the translation into blog post format? |
| 17:30 | <gsnedders> | These automated switches seem very Microsoft-esque |
| 17:31 | <virtuelv> | Philip`: seems to be a my.opera issue |
| 17:31 | <annevk> | gsnedders, dunno, it's just convenience for me, and we can provide documentation |
| 17:40 | <annevk> | web-apps-tracker cache is pretty close to half a gibibyte, no wonder Hixie had some issues now and then :) |
| 17:41 | <Philip`> | You need compression :-) |
| 17:41 | <Philip`> | and expiry, I guess |
| 17:42 | Philip` | 's cache of the issues list is only 27MB, which is boringly small |
| 17:43 | <annevk> | why? I've lots of space |
| 17:43 | <annevk> | no need for expiry either as a diff between 2 and 3 or so is pretty static |
| 17:43 | <annevk> | (unless svn diff changes) |
| 17:44 | <Philip`> | Will you still have enough space by 2022 if you never delete the old cached files? |
| 17:44 | <annevk> | most likely |
| 17:44 | <Philip`> | Okay then |
| 17:45 | <annevk> | I have another 350 gibibyte |
| 17:48 | <Philip`> | That's, uh, quite a bit |
| 17:48 | <Philip`> | You could download a lot of Linux ISO torrents onto that |
| 17:54 | Philip` | wonders if the issue in http://my.opera.com/hallvors/blog/2008/06/06/extending-the-web-is-hard was posted somewhere where people would see it |
| 18:01 | <virtuelv> | Philip`: he submitted it to the daily wtf |
| 18:03 | <virtuelv> | did I dream this up, or did some guy actually write a c compiler in xslt? |
| 18:04 | <Philip`> | s/dream/nightmare/ |
| 18:07 | <annevk> | Philip`, seems to solution is to simply drop support for replace="" ... |
| 18:11 | billyjack | thinks every browser project should have a Hallvord R.M. ... those that don't are severely lacking |
| 18:12 | <Philip`> | Debugging other people's code is never quite as much fun as debugging your own; and debugging your own is no fun at all |
| 18:12 | <billyjack> | yep |
| 18:30 | <virtuelv> | fun fact, hallvord is also (or at least used to be) a professional dancer |
| 18:35 | <billyjack> | contemporary dance, at that |
| 18:49 | <hsivonen> | I wish I could just focus on coding app logic and didn't have to figure out deployment mechanics... |
| 18:53 | <gsnedders> | MUST. STOP. PROCRASTINATING. |
| 19:01 | <Philip`> | gsnedders: Must you stop right now, or could you wait a little while before doing so? |
| 19:01 | <gsnedders> | Ooo… Food! |
| 19:01 | <BenMillard> | gsnedders, good idea. :) |
| 19:02 | <gsnedders> | BenMillard: When will you be arriving to the hotel, roughly? |
| 19:02 | <billyjack> | hsivonen: if you could figure out a way to do that, I know a few product-development organizations that would love to have that insight too |
| 19:02 | <BenMillard> | gsnedders, not quite sure...we are allowed into the room at 14:00 on Friday |
| 19:02 | <BenMillard> | erm, I mean Sunday |
| 19:02 | <gsnedders> | BenMillard: You have any idea if getting there before you will be any problem? |
| 19:03 | gsnedders | hopes not |
| 19:03 | <billyjack> | hsivonen: users/customers create all the real problems |
| 19:03 | <Philip`> | Developing web services is good if you don't like deployment |
| 19:03 | <gsnedders> | I should get there around 16:00 |
| 19:03 | <BenMillard> | gsnedders, all our names are on the reservation and the payment is done so I imagine it should work out alright. |
| 19:04 | <billyjack> | Philip`: I think you meant to refer to Semantic Web technologies |
| 19:07 | <hsivonen> | Lachy: one shouldn't define one's product in relation to a competitor. that said, one audience was amused by the text "Even 100% less Flash" in the corner of a slide pitching HTML5 |
| 19:07 | <Philip`> | billyjack: I agree research technology is easier since you don't need users :-) |
| 19:08 | <Philip`> | (although actually the research project I'm working on is intending to release actual code and actual documentation to actual users in the next few months, which is a bit of a pain but quite useful) |
| 19:08 | <Philip`> | (although "actual users" actually means "other researchers") |
| 19:09 | <billyjack> | once you get real people involved, everything goes all to hell |
| 19:09 | <billyjack> | best to keep it all user-free |
| 19:09 | <billyjack> | like Ted Nelson's Xanadao |
| 19:09 | <billyjack> | Xanado |
| 19:09 | <Philip`> | Xanadu? |
| 19:10 | <billyjack> | yeah, that one |
| 19:10 | billyjack | notes 03:13am here and at least 3 tall cans of Yebisu |
| 19:10 | <Lachy> | hsivonen, I could take out the reference to Flash |
| 19:13 | <Lachy> | hsivonen, is this better: |
| 19:13 | <Lachy> | Web standards and browser vendors are rapidly increasing the possibilities with development using web standards like HTML, CSS and JavaScript. New features are currently under development to to provide designers and developers with more flexibility for creating great looking, interactive and responsive web sites and applications. This presentation will showcase the latest features that you can begin using now or in the near future to enhance the user e |
| 19:13 | <Lachy> | xperience of your site. |
| 19:13 | <Lachy> | hmm, that first sentence doesn't work well |
| 19:13 | <hsivonen> | Philip`: actually, I am developing a Web service |
| 19:14 | <Philip`> | hsivonen: Just be thankful you're not trying to deliver a standalone desktop Java application to a million users ;-) |
| 19:14 | <hsivonen> | Philip`: the problem is that when I have some code ready in Eclipse, replacing the process on the server without visible disruptions is the part I don't like |
| 19:15 | <hsivonen> | My current deployment process requires the server to run the compiler |
| 19:15 | <billyjack> | Lachy: some might argue for "Web standards suck less than they used to because now smarter people are in position to have more influence over what gets standardized." |
| 19:16 | <hsivonen> | I think I want a system where my development machine compiles and pushes a tarball over ssh somewhere |
| 19:16 | <billyjack> | Lachy: though I would not personally endorse any statement like that |
| 19:16 | <Philip`> | billyjack: Alternatively, we just have more hindsight now |
| 19:16 | jgraham | thinks in many cases the million users are the people who lose out from anything involving the words "desktop" and "Java" |
| 19:16 | <hsivonen> | and then it would be great if "somewhere", some automated thingy replaced the existing process so that the move over to the new process would be undetectable from the outside |
| 19:17 | <billyjack> | Philip`: and maybe more foresight too |
| 19:17 | <Lachy> | I think this is better: Browser vendors are working together to develop and implement new, innovative possibilities for developing with web standards like HTML, CSS and JavaScript. ... |
| 19:17 | <Lachy> | s/possibilities/features/ |
| 19:17 | <Philip`> | jgraham: Replace "Java" with "Python" if you want, and it's still quite annoying to distribute to end users |
| 19:17 | <Philip`> | (Or "Perl" for that matter) |
| 19:18 | <jgraham> | Philip`: No arguments there. Just randomly dissing Java-on-the-desktop :) |
| 19:18 | <billyjack> | Lachy: implying that browser vendors are doing it alone seems misleading to me |
| 19:18 | Philip` | has been far happier releasing C++ applications, because it's just an .exe and some .dlls and then it all works, rather than worrying about a zillion module files and poorly-tested executable script wrappers and so on |
| 19:19 | jgraham | just survided a minor panic when he found an error in an equation from 3.5 years ago, which subsequently turned out to be a typo in the writeup |
| 19:19 | <billyjack> | we have perhaps a few cases from the last couple years where browser vendors wouldn't be doing jack unless JS toolkit developers and Gears had not lit a fire under their asses |
| 19:21 | <Lachy> | ok, how's this? |
| 19:21 | <Lachy> | Browser vendors are working together with the community to develop and implement new, innovative features for developing with web standards like HTML, CSS and JavaScript; aiming to provide designers and developers with more flexibility for creating great looking, interactive and responsive web sites and applications. This presentation will showcase the latest features that you can begin using now or in the near future to enhance the user experience of you |
| 19:21 | <Lachy> | r site. |
| 19:21 | <jgraham> | billyjack: Not such a great sentence though "Having finally had a fire lit under their asses by js libraries and Google's gears, browser developers are finally coming together and going 'look, we can innovate too'" |
| 19:21 | <Philip`> | Lachy: What new features are innovative? There's, like, databases which are stone age technology, video which Flash has done for ages, a primitive 2d drawing API, form controls that are slightly less primitive than they used to be, text that you can rotate and animate a bit |
| 19:21 | <billyjack> | jgraham: I love that sentence |
| 19:21 | <hsivonen> | Lachy: here's a translation of the audience-tested Flash reference I had: http://hsivonen.iki.fi/HTML5-percentages.pdf |
| 19:21 | <jgraham> | Lachy: "great looking, interactive and responsive" doesn't sound right |
| 19:21 | <billyjack> | we should carve that in stone |
| 19:21 | <Philip`> | Oh, and there's concurrency, which is hardly a novel idea |
| 19:22 | <billyjack> | on somebody's tombstone |
| 19:22 | <hsivonen> | (there were many more slides in the presentation) |
| 19:23 | <Philip`> | (And taking some old technology X and creating a new technology "X on the Web!" is not innovation) |
| 19:23 | <jgraham> | Lachy: Because it's not clear if great is supposed to apply to all three items in the list and because there are already interactive websites |
| 19:24 | <billyjack> | Philip`: making video work without relying on third-party plugins seems like real innovation to me |
| 19:24 | Lachy | wants to go back to the original generic abstract that didn't have so many complications |
| 19:24 | <billyjack> | Lachy: welcome to the Web |
| 19:25 | <jgraham> | Lachy: What's the talk title? |
| 19:25 | <billyjack> | if we could just get rid of all the complications, everything would be so easy |
| 19:25 | <Lachy> | the title should probably change now that I've removed the flash stuff |
| 19:25 | <Philip`> | billyjack: I don't see how that's innovation - it's just picking up some third-party video rendering libraries and hooking them into your web browser codebase. It's not the kind of thing to make you say "wow, I never would have thought of doing anything like that" |
| 19:26 | <Lachy> | Philip`, allowing authors to control the video using a DOM API using javascript is innovative |
| 19:26 | <billyjack> | Philip`: well, OK, Web Sockets is more innovative at least. |
| 19:26 | <Philip`> | Lachy: Plugins expose APIs to let JS control the video too |
| 19:26 | <gsnedders> | ooo… CSS are playing in Edi! |
| 19:26 | <gsnedders> | Oh, wait, I'm in France then. :( |
| 19:27 | billyjack | sees a curve where the most innovative parts of HTML5 are the same part that have near-zero chance of actually getting implemented |
| 19:27 | <gsnedders> | And over 18s only. |
| 19:27 | <gsnedders> | I suck. |
| 19:29 | <Philip`> | billyjack: Sockets are old technology, and so "sockets, on the Web!" is not exactly a great innovation :-p |
| 19:30 | <Lachy> | Browser vendors are working together with the community to develop and implement new and improved features for developing with web standards like HTML, CSS and JavaScript; aiming to provide designers and developers with more flexibility for creating [insert adjective] web applications applications. This presentation will showcase the latest features that you can begin using now or in the near future to enhance the user experience of your site. |
| 19:30 | <jgraham> | Lachy: You should probably start by talking about HTML 5. So something like "HTML 5 is bringing cool exciting stuff to the web meaning that you'll be able to make better webapps than you could before" |
| 19:30 | <Lachy> | jgraham, I was intending to cover more than just HTML5 |
| 19:30 | <jgraham> | s/better/more-desktop-like/ |
| 19:31 | <billyjack> | Lachy: bo-ring |
| 19:31 | <Lachy> | billyjack, wtf? |
| 19:31 | <jgraham> | Lachy: What? Selectors API? You probably don't need to be precise in the abstract |
| 19:32 | <Lachy> | CSS transforms are also on my list |
| 19:32 | <jgraham> | Normal people don't care which document a feature is in although they do put some weight on whether it has a blue heading and a W3C logo graphic |
| 19:32 | <jgraham> | Just say New develpoments in HTML 5 and CSS or something then. |
| 19:33 | <Philip`> | We're not going to object if you pretend that all the other cool stuff happening on the web is part of HTML 5 |
| 19:33 | <Philip`> | That's just good marketing |
| 19:33 | <hsivonen> | is the Dirac demo content on the Web already? how does the decoder perform in terms of CPU requirements compared to H.264? |
| 19:33 | <jgraham> | Are the CSS working group actually going to do CSS transforms? |
| 19:34 | <billyjack> | jgraham: I doubt they will |
| 19:34 | <jgraham> | It will be pretty ironic to get two interoperable implementations and no working group that will touch it |
| 19:34 | <Philip`> | Is anyone else going to do CSS transforms? |
| 19:34 | <Lachy> | I hope they will, since webkit and mozilla are implementing them |
| 19:34 | <jgraham> | Although I guess irony implies some unexpectedness :( |
| 19:35 | <Lachy> | jgraham, that's the same situation we've had for years with proprietary extensions |
| 19:35 | <billyjack> | well, we have the great precedent of the Apple/WebKit guys just doing an absolutely brilliant job on their own of spec'ing out canvas |
| 19:36 | <Philip`> | They had to document it in enough detail to put in their patent application, but not much more than that ;-) |
| 19:36 | <billyjack> | so I think we should just have faith that they've done an equally good job on CSS tranforms and everybody else should just implement it the way they spec(ed it |
| 19:36 | <jgraham> | Lachy: Well eventually much of the useful stuff got picked up. OTOH, how many proprietry extensions had people going up to the W3C and begging them to standardise it, only to be refused? |
| 19:38 | <Lachy> | the W3C have a history of refusing things at first, though more recently, they've turned around and done something about some things |
| 19:39 | <Lachy> | CSS variables is one case that they often rejected, until recently |
| 19:40 | <Lachy> | oh, that's another thing I could talk about |
| 19:41 | <billyjack> | I for one fully support the evolution of CSS into a half-assed Turing-complete language |
| 19:42 | <hsivonen> | I think I don't want CSS to become Turing-complete |
| 19:42 | <gsnedders> | I see no use for it |
| 19:42 | <Philip`> | IE8 seems to be evolving away from that, which is good |
| 19:43 | <Lachy> | billyjack, if that's what you want, we could go back to that old JavaScript style sheets proposal that came from Netscape, IIRC |
| 19:43 | <jgraham> | Eh, I thought CSS variables were more like CSS constants meaning you could do things like defining a shade of grey and using it everywhere |
| 19:43 | <hsivonen> | Lachy: or XSLT or DSSSL |
| 19:44 | <Lachy> | hsivonen, no, XSLT is complicated and DSSSL is hard to say |
| 19:44 | <billyjack> | Lachy: i'm for anything that would save use from selectors syntax |
| 19:44 | <Lachy> | why? what's wrong with selector syntax? |
| 19:44 | <Philip`> | jgraham: Presumably they're using the mathematical meaning of "variable", which is just a rebindable named constant |
| 19:44 | <Lachy> | it's significantly better than xpath |
| 19:45 | <billyjack> | Lachy: nothing. it's absolutely perfect. you're riht |
| 19:45 | <Lachy> | ok |
| 19:46 | <billyjack> | the relative logic and regularity of xpath syntax is a serious misfeature |
| 19:47 | <billyjack> | we should all prefer arbitrary symbols reminiscent of perl |
| 19:47 | <hsivonen> | namespaces make XPath much worse |
| 19:47 | <Lachy> | what logic in xpath? It's so confusing, and I can never get it right the first time |
| 19:47 | Philip` | approves of anything reminiscent of Perl |
| 19:47 | <hsivonen> | we should all do s-expressions instead of these angular tags |
| 19:47 | <billyjack> | perl++ |
| 19:48 | <billyjack> | hsivonen: rms++ |
| 19:48 | <Philip`> | billyjack: I think you mean $perl++ |
| 19:48 | <billyjack> | heh |
| 19:48 | <Philip`> | (Hooray for magic increment operator!) |
| 19:48 | <Philip`> | (++$perl is sadly non-magic, if I'm remembering it the right way around) |
| 19:49 | <hsivonen> | so will Perl 6 be Ready before 2022? |
| 19:49 | <Philip`> | (Oh, maybe they're both magic) |
| 19:50 | <Philip`> | hsivonen: What does "Ready" mean? I wrote and executed a Perl 6 program two years ago, and it even worked |
| 19:50 | <Philip`> | albeit extremely slowly, in an interpreter written in Haskell |
| 19:50 | <Philip`> | and several basic language features weren't implemented |
| 19:50 | <Philip`> | but it worked |
| 19:50 | <hsivonen> | Philip`: was the Haskell interpreter for Perl syntax or for Parrot bytecode? |
| 19:51 | <Philip`> | hsivonen: It was just Haskell, no Parrot |
| 19:51 | <hsivonen> | Philip`: someone must have had fun writing the whole parser in Haskell |
| 19:52 | <Philip`> | hsivonen: They intentionally optimised for fun |
| 19:52 | <hsivonen> | Philip`: I guess it's Ready when Linux distros install Perl 6 by default and users don't install Perl 5 anymore |
| 19:52 | <Philip`> | http://www.onlamp.com/pub/wlg/7996 |
| 19:53 | <hsivonen> | clearly, Perl 5 is Ready compared to Perl 4 by now |
| 19:53 | <Philip`> | That's largely because almost nobody used Perl 4 |
| 19:53 | <Philip`> | but now almost everybody uses Perl 5 |
| 19:53 | <Philip`> | so there's rather a lot more legacy |
| 19:55 | <Philip`> | (And I think Perl 5 was mostly a superset of Perl 4, which isn't true of 6 vs 5) |
| 19:56 | <Philip`> | (so it's probably better to think of Perl 6 as an independent language, like Python or Ruby but crazier) |
| 19:57 | <Lachy> | how is this now? |
| 19:57 | <Lachy> | New developments in web standards like HTML, CSS and JavaScript are aiming to provide designers and developers with more flexibility for creating and enhancing web sites and applications. This presentation will showcase the latest features currently being implemented in browsers, including new JavaScript APIs, improved multimedia support and CSS. |
| 19:57 | <hsivonen> | will CPAN fork? |
| 19:57 | <jgraham> | s/are aiming to/will/ |
| 19:58 | <Lachy> | ok |
| 19:58 | <jgraham> | I'm not sure how one "enhances" a website |
| 19:58 | <Lachy> | they do it by using the new features |
| 19:58 | <jgraham> | But don't actually use the word "will" because you use it later |
| 19:58 | <Lachy> | what's wrong with "are aiming to"? |
| 19:59 | <jgraham> | It sounds too much like we might fail. Plus its not really true, we've already suceeded in as much as its been implemented in some places |
| 20:00 | <jgraham> | You're trying to get people to come so be positive |
| 20:00 | <jgraham> | Why "more flexibility"? |
| 20:00 | <Lachy> | cause it sounded good |
| 20:00 | <jgraham> | Would something like "better tools" work? |
| 20:01 | <jgraham> | (I don't want flexibility, I want goodness) |
| 20:01 | <Lachy> | ok |
| 20:01 | <Philip`> | hsivonen: No idea - there's a cpan6.org, but it sounds like that's not trying to be a CPAN for Perl 6 any more |
| 20:02 | <Lachy> | New developments in web standards like HTML, CSS and JavaScript are providing designers and developers with better tools for creating and enhancing web sites and applications. This presentation will showcase the latest features currently being implemented in browsers, including new JavaScript APIs, improved multimedia support and CSS. |
| 20:03 | <jgraham> | Lachy: I think you could s/and enhancing/ with some adjectives describing the types of web sites. Like "advanced". But maybe that's cutting out the fact that it also works for simple sites |
| 20:03 | <jgraham> | s/applications/web applications/ |
| 20:04 | <Lachy> | I tried using some adjective there before, but people complained |
| 20:04 | <jgraham> | I think that was me :) |
| 20:05 | <Lachy> | I didn't want to say "web sites and web applications" |
| 20:05 | <jgraham> | Otherwise, it sounds good. I would add version numbers to the specs |
| 20:05 | <jgraham> | HTML 5 CSS 3 and JS 2 |
| 20:06 | <jgraham> | Maybe it reads better without web repeated |
| 20:06 | <Lachy> | well, JS 2 is just the name of Mozilla's implementation of JavaScript, and I'm really referring to DOM APIs |
| 20:06 | <Lachy> | but the term JavaScript seems a bit more marketable than DOM |
| 20:07 | <jgraham> | I thought JS2 == Ecmascript 3.1, these days, which is what I assumed you meant |
| 20:07 | <jgraham> | If you just mean DOM, don't say anything. You say javascript APIs later |
| 20:07 | <Lachy> | JS2 is an implementation of ES3 |
| 20:08 | <jgraham> | Well whatever, but I would still expect your talk to include information about ES3.1 based on that abstract |
| 20:08 | <Lachy> | New developments in web standards like HTML 5 and CSS 3 are providing designers and developers with better tools for creating and enhancing web sites and applications. This presentation will showcase the latest features currently being implemented in browsers, including new JavaScript APIs, improved multimedia support and CSS. |
| 20:09 | <jgraham> | I still don't like "and enhancing" but otherwise it sounds good |
| 20:09 | <Lachy> | I don't have anything to replace it with |
| 20:10 | <jgraham> | Well I'm going home now so there's not much I can do about it :) |
| 20:10 | Lachy | looks up a thesaurus |
| 21:26 | gsnedders | wonders how on earth to start a personal statement |
| 21:27 | <gsnedders> | (the current start is from lack of any better non-cliché idea) |
| 21:27 | <gsnedders> | jgraham: What would you think if I just removed the first sentence? |
| 21:54 | <gsnedders> | hahaha. Yeah, jgraham, I did mean to say _why_ I missed school. |
| 21:55 | <gsnedders> | I wanted to go to bed by the time I wrote that :) |
| 22:09 | <gsnedders> | jgraham: What do you think of just switching phys./comp.sci. around? |
| 22:22 | <Philip`> | gsnedders: In case nobody has mentioned this already: The first two paragraphs seem to have a fair amount of irrelevant details - the reader isn't going to bother visiting a web site so there's no point giving URLs, and they don't care about the exact names of groups or software |
| 22:25 | <Philip`> | Also it seems a bad idea to list things that you don't know - I expect it'd be much better to describe something you didn't know, but took the initiative to learn yourself |
| 22:28 | <Philip`> | Maybe you could start with the bit about why you're interested in physics and CS because you like understanding all the details of how a system works, and then go onto the more specific bits about interesting physicsy things and experience with computery stuff |
| 22:31 | <Philip`> | Also it might be good to go into more detail about what was involved in working in (presumably) a group on SimplePie, like how many other people were involved and what responsibilities you had, since everyone says teamwork is a good thing to say you can demonstrate |
| 22:37 | <gsnedders> | Philip`: email plz :P |
| 22:39 | <Philip`> | gsnedders: I've got bored of thinking of things to say now :-p |
| 23:00 | <Hixie> | can anyone think of anything I should add to http://www.whatwg.org/specs/web-apps/current-work/#text2 other than stuff specific to the attributes listed in the penultimate paragraph of that section? |
| 23:01 | <annevk> | shouldn't it remove more line characters? |
| 23:03 | <Hixie> | like what? |
| 23:03 | <annevk> | CR? |
| 23:03 | <Hixie> | CR isn't a line break character in html5 is it? |
| 23:03 | <annevk> | you can insert it through the DOM |
| 23:04 | <Hixie> | sure but i mean it's no different than inserting a U+000\1 |
| 23:04 | <Hixie> | U+0001 even |
| 23:04 | <annevk> | it's counted as a space character |
| 23:04 | <annevk> | FF too btw |
| 23:06 | <Lachy> | Hixie, "If the input element is not dirty then set...", can you link the word dirty to the definition of the dirty state |
| 23:06 | <Lachy> | dirty flag* |
| 23:09 | <annevk> | "The autocomplete attribute is an enumerated attribute." enumerated attribute is not a pointer |
| 23:09 | <annevk> | prolly because the dfn is plural |
| 23:11 | <annevk> | that's not it |
| 23:11 | <jgraham> | gsnedders: Switching the phy/comp sci around might help |
| 23:11 | <annevk> | it simply misses <span> |
| 23:11 | jgraham | wonders if gsnedders is actually around atm |
| 23:12 | <Hixie> | annevk: fixed the dirty flag and enumerated attribute xref problems |
| 23:12 | <Hixie> | looks like IE strips \n and \r and leaves everything else |
| 23:12 | <Hixie> | so i'll do that |
| 23:13 | <annevk> | I expected as much :) |
| 23:27 | <annevk> | Hixie, having a normative table that says which attributes can be specified on <input> depending on the state would be much better than two paragraphs at the end of each state |
| 23:28 | <annevk> | as you did in http://www.whatwg.org/specs/web-forms/current-work/#summary |
| 23:28 | <Hixie> | yeah, i was thinking of having both |
| 23:29 | <Hixie> | the paragraph is useful because then it's right there |
| 23:29 | <Hixie> | with the rest of the state's definition |
| 23:29 | <annevk> | I suppose |
| 23:29 | <annevk> | if you can keep it all in sync :) |
| 23:29 | <Hixie> | wf2 had two too |
| 23:30 | <Hixie> | it had the table in the appendix and a paragraph for each atribute |
| 23:31 | <annevk> | so is each attribute also getting a paragraph stating for what states it can be used? |
| 23:31 | <Hixie> | no |
| 23:33 | <Hixie> | you can find out who autocomplete is applicable to by clicking teh definition of the attribute |
| 23:34 | <annevk> | fair enough, I suppose |
| 23:34 | <Hixie> | gotta go |
| 23:34 | <Hixie> | bbiab |