| 00:05 | <Hixie> | cool |
| 00:27 | <Philip`> | http://molly.com is interesting in Links, since it has fifty lines of "Link: favicon", "Link: pingback", "Link: archives: August 2007", ... at the top of the screen, followed by the "skip to the content" link at the top of the third page |
| 00:29 | <Philip`> | (Perhaps that counts as an indication that it'd be nice if pages identified where their content was and let the UAs add a skip-to-content link in an appropriate part of their UI) |
| 01:53 | <othermaciej> | Hixie: what would an implementation have to do to support the new semantic block-level elements? |
| 01:54 | <othermaciej> | Hixie: would it be appropriate to give them default style of display: block, or no? |
| 01:54 | <othermaciej> | Hixie: is it necessary to do some special rendering of <h1> - <h6> in the presence of sectioning elements? |
| 01:54 | <othermaciej> | Hixie: I'm wondering because those seem like some of the least controversial additions in the spec, but I'm not sure what, if anything, implementations should do for those elements |
| 01:58 | <Lachy> | othermaciej, display: block; for them would be very useful |
| 01:59 | <Lachy> | I'm not sure about heading rendering though |
| 01:59 | <othermaciej> | Lachy: I could see arguments either way - if they don't have display: block, content authors will be more likely to make documents that degrade gracefully by explicitly setting display: block |
| 01:59 | <othermaciej> | I'm not sure what Hixie's intent was |
| 02:02 | <Lachy> | I think content authors will still set display: block for them to be compatible with legacy UAs during the transitional period until most UAs support them, though I think having the default has display: block; would be the most logical |
| 02:02 | <Lachy> | I think the bigger issue of backwards compatibility is the differences in parsing for known vs. unknown elements |
| 02:03 | <othermaciej> | is there a parsing difference per spec? |
| 02:06 | <Lachy> | no, I meant the way in when legacy UAs will handle them as unknown elements and new UAs will parse them more sensibly |
| 02:06 | <Lachy> | although they're not in the parsing algorithm yet (last time I checked), I assume the sectioning elements will end up being parsed more like div |
| 05:28 | <Hixie> | othermaciej: my intent (unsure whether it's workable in reality) is for <h2>-<h6> to continue as is, for all the new block-level elements to have display:block as a style, and for <h1> to automatically style appropriately according to the section depth as defined by the outline section |
| 05:29 | <Hixie> | othermaciej: but i have no idea if that is practical back-compat wise, let alone if it is implementable with good perf |
| 05:30 | <G0k> | hixie: did you get a chance to look at that event-source stuff yet? |
| 05:30 | <G0k> | oh wait i got an email back from you |
| 05:53 | <G0k> | oh heh actually i have another question about that |
| 05:55 | <G0k> | if you have >1 RemoteEventTarget node within a single document, and they all get the same event source URI added to them, should the UA open one connection for each object, or just open one and then dispatch events from that connection to all the listeners? |
| 06:12 | <Hixie> | G0k: i believe the spec unambiguously requires the former |
| 06:14 | <G0k> | hm. isn't there like a 2 HTTP connections per UA rule per server? |
| 06:14 | <Hixie> | yes, i wouldn't recommend that people have more than one of these things |
| 06:15 | <G0k> | yeah i suppose that makes sense |
| 06:17 | <G0k> | and is there like a pre-draft of what the Access-Control HTTP header might look like? |
| 06:27 | <Hixie> | yeah |
| 06:27 | <Hixie> | www.w3.org/tr/access-control or some such |
| 06:30 | <G0k> | ah |
| 06:42 | <G0k> | i guess this is the wrong place to ask this, but i don't understand what this is supposed to accomplish |
| 06:47 | <G0k> | so i put a document on server-a.com, then another resource on server-b.com, and i want the server-a document to access the server-b resource....so now i have to make server-b.com provide an HTTP header that says it's ok for that to happen? |
| 06:48 | <Hixie> | yeah |
| 06:48 | <G0k> | how is this better than just having server-b check the Referer field? |
| 07:10 | <Hixie> | most servers don't check the referer field |
| 07:11 | <Hixie> | so if we relied on that, most servers would be vulnerable today |
| 07:11 | <G0k> | but...zero servers check the Content-Access-Control fiel |
| 07:11 | <G0k> | *d |
| 07:11 | <Hixie> | no the server has to _send_ the field |
| 07:11 | <G0k> | i guess i'm not clear who's being protected here |
| 07:12 | <Hixie> | the user is being protected from server-a pretending to be the user when talking to server-b |
| 07:15 | <G0k> | ah ok so this could prevent the resource from server-b, which is accessed by the user directly, from being sent back to server-a? |
| 07:16 | <Hixie> | right |
| 07:16 | <Hixie> | (on an unrelated note, http://www.w3.org/mid/20070808115703.GC5388⊙sc summarises where i'm coming from regarding the wysiwyg stuff) |
| 07:17 | <G0k> | though it requires server-b to implement it, and the UA to implement it, and also requires breaking all other current cross-domain communication techniques? |
| 07:18 | <Hixie> | no |
| 07:18 | <Hixie> | it requires server-b to implement it only if server-b wants to allow access |
| 07:19 | <Hixie> | it requires the UA to implement it only if the UA is to support cross-domain stuff |
| 07:19 | <Hixie> | and it doesn't affect any existing cross-domain features |
| 07:22 | <G0k> | ok but tricks like dom-inserting a <script> element could still get around this |
| 07:23 | <Hixie> | dom-inserting a script only works if you're inserting a script |
| 07:23 | <Hixie> | so yes, scripts aren't protected |
| 07:30 | <G0k> | ok but...let's say server-b doesn't want server-a's web pages from loading its images |
| 07:30 | <G0k> | it could say Content-Access-Control: deny server-a.com |
| 07:31 | <G0k> | but that would only be honored by new UAs |
| 07:32 | <G0k> | i mean i guess that's somewhat outside the scope of access control's purpose |
| 07:33 | <G0k> | but it's something of an broken-at-conception default behavior |
| 07:42 | <Hixie> | G0k: images are also not affected by this |
| 07:43 | <Hixie> | G0k: this doesn't affect anything that is allowed now |
| 07:43 | <Hixie> | G0k: it only affects new cross-domain stuff |
| 07:43 | <G0k> | so it only applies in situations where the same origin policy is currently being used? |
| 07:43 | <Hixie> | it only applies in situations where the specs say it applies :-) |
| 07:44 | <G0k> | yeah right so "To facilitate clear and controlled read access to resources, this specification defines a read access control mechanism that enables a web resource to permit access to its content from external domains when such access would otherwise be prohibited by a same origin policy." |
| 07:44 | <G0k> | i guess my question is....is there a formal definition of when the same origin policy is used? |
| 07:45 | <G0k> | i mean clearly it seems to always apply to XMLHttpRequest stuff |
| 07:46 | <G0k> | and presumably the event-source gunk |
| 07:47 | <G0k> | or is it just always left up the implementation? |
| 07:49 | <Hixie> | access-control only applies in situations where the specs explicitly say it applies |
| 07:49 | <Hixie> | so e.g. xmlhttprequest |
| 07:49 | <Hixie> | or rather xmlhttprequest2 |
| 07:50 | <G0k> | ooo the sequel |
| 07:50 | <Hixie> | because that spec says it applies |
| 07:50 | <Hixie> | same with xbl2 |
| 07:50 | <Hixie> | xbl2 says it applies |
| 07:52 | <G0k> | alright |
| 07:53 | <G0k> | well i guess that was a key point i was missing |
| 07:53 | <G0k> | i thought it was more of a replacement for previous access control methods |
| 07:56 | <Hixie> | nope |
| 08:02 | <Hixie> | oops, replied to a thread that already got replies |
| 08:02 | <Hixie> | i need to remember to read the whole thread before replying |
| 08:10 | <zcorpan_> | Hixie: what is the legacy parsing behaviour for <address> you're referring to? firefox's behavior? |
| 08:19 | <Hixie> | "address" is mentioned in all kinds of places in the parser |
| 08:20 | <zcorpan_> | i only find two "address" in the parsing section |
| 08:22 | <Whiskey_M> | 'lo |
| 08:23 | <zcorpan_> | morning Whiskey_M |
| 08:23 | <Whiskey_M> | Good morning, how goes today? |
| 08:24 | <zcorpan_> | tired... woke up 5am this morning |
| 08:24 | <Whiskey_M> | ouch, lots of coffee today then |
| 08:25 | <zcorpan_> | nah |
| 09:17 | <met_> | http://therealcrisp.xs4all.nl/blog/2007/08/13/getelementsbyclassname-re-re-re-visited/ see also crisp comment |
| 10:31 | <virtuelv> | exactly what is Molly talking about here? http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/ |
| 10:32 | <virtuelv> | I simply don't get what she's trying to point out |
| 10:37 | Dashiva | considers a humorous comment, but decides it's just going to end up in another angry mail some time in the future |
| 11:01 | <gsnedders> | virtuelv: the impression I got is W3C's long-term vision for the web (XML) |
| 11:01 | <gsnedders> | and that HTML5 is undermining that |
| 11:02 | <virtuelv> | I _still_ don't get it |
| 11:03 | <gsnedders> | Why is HTML5 being developed at all? It's undermining everything (XML)! Why isn't WaSP and the like doing anything about it? |
| 11:04 | <virtuelv> | xml pretty much undermined itself as a language for end-user display on the web when it defined draconian error handling anyway |
| 11:05 | <gsnedders> | It's obvious that from Molly's POV it _must_ be the future of the web |
| 11:05 | <Whiskey_M> | just a quick one - it's not XML you are talking about, rather XHTML (although the error handling does come from XML parsers) |
| 11:06 | <gsnedders> | Whiskey_M: The W3C's vision is to use XML for everything though, not just XHTML |
| 11:06 | <virtuelv> | Whiskey_M: note that XHTML as text/html is not XHTML |
| 11:08 | <Whiskey_M> | gsnedders, most things yes (and for a lot it works well), virtuelv - if you're on about serving, although transitional format does allow text/html - you're right |
| 11:08 | <Whiskey_M> | heading for tea |
| 11:08 | <gsnedders> | Whiskey_M: all XHTML 1.0 DOCTYPEs are allowed under text/html |
| 11:09 | <virtuelv> | Whiskey_M: note that no: xhtml as text/html is never parsed using an xml parser |
| 11:09 | virtuelv | points to http://www.hixie.ch/advocacy/xhtml'; |
| 11:09 | <virtuelv> | err, http://www.hixie.ch/advocacy/xhtml |
| 11:10 | <gsnedders> | virtuelv: that's not what he's saying. |
| 11:10 | <gsnedders> | virtuelv: he's saying you're allowed to serve it as text/html. |
| 11:10 | <gsnedders> | virtuelv: what it is parsed as is a whole different matter |
| 11:10 | <virtuelv> | yes, I am not denying that. I'm just saying that you SHOULD NOT |
| 11:11 | <virtuelv> | (I do it on my site, but will stop doing so once I get time to rework the templates) |
| 11:11 | <gsnedders> | virtuelv: then why the "no"? |
| 11:12 | <virtuelv> | gsnedders: because by the time you're doing it, it may have an "xhtml" doctype, but the browser doesn't treat it as such |
| 11:12 | <gsnedders> | virtuelv: but that still doesn't contradict the statement that you can serve it as text/html |
| 11:12 | <zcorpan_> | virtuelv: with what expected benefit except perhaps for a few saved bytes and a pat on the back? re rework the templates |
| 11:14 | <virtuelv> | zcorpan_: just changing the doctype has no real-world benefit as such |
| 11:15 | <zcorpan_> | virtuelv: indeed |
| 11:15 | <virtuelv> | but that isn't the point of redoing the templates. It's rather to get rid of cruft, and incorporating a few html5 features |
| 11:15 | <zcorpan_> | ok |
| 11:16 | <virtuelv> | but it's more of a project utopia, given that I never have the time to do it anyway :-P |
| 11:16 | <gsnedders> | but in the real-world you don't need to redo it to add HTML 5 features |
| 11:16 | <zcorpan_> | removing cruft might need redoing :) |
| 11:17 | zcorpan_ | -> lunch |
| 11:17 | <gsnedders> | my redesign has gone through so many phases I have no idea what sort of markup it has |
| 11:17 | <gsnedders> | probably HTML 4.01 Strict |
| 11:18 | <gsnedders> | an earlier concept of the redesign was XHTML 1.1, but that was all scrapped anyway |
| 11:28 | <Whiskey_M> | gs / virt: On reading the piece and without wanting to put words in Molly's mouth - it would seem to say that although a lot of people, companies and organisations are putting together a lot of good work there does seem to be some pulling in different directions, some of the stuff (AIR), doesn't appear to sit comfortably in standards (also between AIR and Silverlight are we going to see a new "browser wars"), and the normal bodies tha |
| 11:33 | <mpt> | Whiskey_M, "...and the normal bodies th" |
| 11:33 | <Whiskey_M> | mpt? |
| 11:33 | <mpt> | you got cut off |
| 11:33 | <Whiskey_M> | ahhh, sorry |
| 11:34 | <Whiskey_M> | and the normal bodies that you'd expect to try to bring people / companies / organisations together aren't really saying / doing anything about it |
| 11:34 | <Whiskey_M> | btw. I'm neither advocating or disagreeing with the opinion - just how I understood it |
| 11:35 | <hsivonen> | Silverlight is a rather big elephant in the room on Molly's blog. :-( |
| 12:34 | <krijnh> | "GET /irc-logs/html-wg/ HTTP/1.1" 302 5 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)" |
| 12:34 | <krijnh> | :O |
| 12:36 | zcorpan_ | fires up Mosaic |
| 13:00 | <met_> | heh, we has even one IE4 hit today http://en.navrcholu.cz/Statistics/58501/browsers-versions/?s=13.8.2007&e=13.8.2007&p=h&pi=1 |
| 13:01 | met_ | found also one hit from Mozilla Suite 1.1 |
| 13:02 | <krijnh> | 38% Fx ? :| |
| 13:08 | Philip` | probably leaves an unusual log trail of IE6+Win98 when looking around in IE in Wine |
| 13:15 | <krijnh> | "...demeaning comments regarding accessibility issues and "smell-o-vision". [http://krijnhoetmer.nl/irc-logs/whatwg/20070701#l-217]"; |
| 13:15 | <krijnh> | And thank you guys for putting those comments on my site! ;) |
| 13:17 | <krijnh> | I should have a disclaimer somewhere.. |
| 13:24 | <met_> | krijnh, of course it site for Mozilla/FF users 8-) |
| 13:24 | <krijnh> | met_: Ah :) |
| 13:24 | <met_> | but we have MUCH better if you want http://en.navrcholu.cz/Statistics/81644/browsers-families/?s=13.8.2007&e=13.8.2007&p=h&pi=1 |
| 13:25 | <krijnh> | You call that much better? Opera has only 1 visit :( |
| 13:25 | <zcorpan_> | yeah :( |
| 13:26 | <met_> | 99.8% of Gecko, I like it 8-) |
| 13:27 | <met_> | wait Opera has 1/3 or IE usage ther, it's cool, isn't? |
| 13:27 | <met_> | and if you wisit the page once you can increase is twice 8-) |
| 13:29 | <zcorpan_> | done already |
| 13:30 | <met_> | btw http://xhtml.com/en/future/fixing-the-web-1/ |
| 13:35 | <mpt> | I don't understand what's so demeaning about smell-o-vision, honestly |
| 13:36 | <mpt> | It was the best example I could think of, because smell is a medium that is very poorly supported |
| 13:36 | <mpt> | actually, that's not quite right |
| 13:37 | <mpt> | Smell is a sense that is supported in very few media. |
| 13:37 | <mpt> | So whenever you watch someone's holiday video, for example, you're missing out on all the wonderful smells |
| 13:38 | <mpt> | but the narrators of such videos *usually* don't mention them, unless they're particularly noteworthy. |
| 13:38 | <mpt> | Similarly, when you listen to radio documentaries, you're missing out on the appearance of all the things being discussed |
| 13:39 | <mpt> | but the narrator usually doesn't mention the appearance of things, unless it's relevant to the topic at hand. |
| 13:40 | <mpt> | (Podcast hosts who say "I'll put the picture of X in the show notes" are the clumsy exception, rather than the rule.) |
| 13:42 | <mpt> | So, I don't think that HTML's accessibility features for people with visual impairments, for example, should take the attitude of "And here's what you would be able to see if you weren't so blind". |
| 13:42 | <mpt> | (Which is what longdesc= does.) |
| 13:43 | <takkaria> | s/does/tries to do/ ;) |
| 13:43 | <mpt> | yeah |
| 13:43 | <krijnh> | Again, I need a disclaimer ;p |
| 13:44 | <mpt> | Rather, I think that they should concentrate on producing the best self-contained text-only version possible |
| 13:44 | <Whiskey_M> | mpt - thinking of an example where longdesc would be appropriate ... describing a chart / graph, just thinking of one of hand |
| 13:46 | <mpt> | Whiskey_M, perhaps, though I think a long alt= could get 90% of the effect. |
| 13:46 | <Whiskey_M> | off hand, sorry |
| 13:47 | <takkaria> | talking of longdesc, I should go over some more URLs and see how many use longdesc correctly |
| 13:47 | <mpt> | Sometimes the best text equivalent to a graph would be a <table>, though |
| 13:47 | <hsivonen> | mpt: out of curiosity, do you work on usability for the general population these days or does your dayjob also involve accessibility issues? |
| 13:47 | <mpt> | which is why the <object> situation is so sad |
| 13:48 | <Whiskey_M> | don't know - would perhaps be overkill for alt. Say we can a graph of user agent usage over the last 12 months - the alt would be "graph of user agent usage over the last 12 months" - the longdesc could give a rough breakdown of the numbers etc. apparent through the chart |
| 13:48 | <gsnedders> | how much content actually relies on IE's treatment of |object|? |
| 13:48 | <zcorpan_> | Whiskey_M: that wouldn't be very good alt text |
| 13:48 | <mpt> | hsivonen, the general population, but a few days ago we had someone on our mailing list who is blind and has trouble with a few pages |
| 13:49 | <Whiskey_M> | zcor: yeah I know |
| 13:49 | <Whiskey_M> | but at the same time you wouldn't want the full breakdown of the data thrown at you in an alt |
| 13:49 | <zcorpan_> | why not? |
| 13:50 | <mpt> | Whiskey_M, perhaps minimums and maximums, or starting and ending values, for each series in the graph |
| 13:51 | <mpt> | for those at least, you have a fair shot at being able to auto-generate them |
| 13:51 | <mpt> | (we have bar charts with auto-generated alt= on our site) |
| 13:51 | <Whiskey_M> | because on something like that it would take too long, especially if it were only suplimental information backing up the rest of the information on the page. Better alt contains an overview and longdesc (if there were one), had the additional information for anyone that wanted to delve in |
| 13:51 | <hsivonen> | mpt: any user feedback on the autogenerated alts? |
| 13:52 | <mpt> | hsivonen, no |
| 13:53 | <zcorpan_> | Whiskey_M: how would you present the information in a text-only context? have a brief overview and a link to a separate page for more detail? |
| 13:53 | <mpt> | I suppose if a graph accompanies a news story where the salient changes are already described in text, the alt= should go into deeper detail, because anyone listening to the graph has already listened to the article |
| 13:54 | <Whiskey_M> | thats what throws me zcorpan - I'm aware longdesc should point to a text resource of more info, but must admit to never seeing it done (not even as an example on accessify forum) |
| 14:08 | <Whiskey_M> | Zcor: thinking about how I'd present that info - probably in a table, user agent / month as the two axis |
| 14:11 | <Whiskey_M> | my bad, look and you will find... http://www.accessifyforum.com/viewtopic.php?t=1807 |
| 14:21 | <gsnedders> | Hixie: how come the WHATWG WD is 11th Aug, and SVN is 10th? |
| 14:22 | <Philip`> | gsnedders: http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-324 |
| 14:23 | <gsnedders> | ah |
| 14:28 | <hsivonen> | http://www.sitepoint.com/blogs/2007/08/13/nihilism-accessibility-and-the-preponderence-of-amazing-co-incidences/ |
| 14:28 | <hsivonen> | "the microformats community and WHATWG are behaving like cabals in their self-interested refusal to acknowledge the accessibility issues with that they’re doing" |
| 14:29 | <takkaria> | sigh |
| 14:35 | <Lachy> | wow, the misconceptions spreading througout the web are getting out of hand |
| 14:42 | <takkaria> | that comment seems to be a throwaway line before a somewhat existentialist rant about nothing in particular |
| 14:42 | <Lachy> | takkaria, my comment? |
| 14:43 | <takkaria> | no, the "the microformats community and WHATWG are behaving..." quote mentioned above |
| 14:43 | <Lachy> | oh, I thought mine because I am actually writing a rant right now :-) |
| 14:43 | <sirPalook> | Hi. I believe that end tag </li> should be completely ignored. |
| 14:44 | <sirPalook> | Here is why: |
| 14:44 | <Lachy> | sirPalook, yes, IIRC, that idea has been mentioned before |
| 14:45 | <sirPalook> | In <ul><ul><li></li></li></ul></ul>, there is an extra </li> which has the effect of closing the <ul> |
| 14:45 | <sirPalook> | This *does* happen in some pages on the internet (gcc archives) |
| 14:45 | <sirPalook> | And neither mozilla nor any other browser act like that. |
| 14:46 | <zcorpan_> | sirPalook: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011884.html |
| 14:46 | <Lachy> | why would the second </li> close the <ul>? Is that in the spec's algorithm? |
| 14:46 | <sirPalook> | html5lib closes it. |
| 14:47 | <sirPalook> | um, sorry, maybe there is another <li> in the outer list... |
| 14:47 | <sirPalook> | revised example <ul><li><ul><li></li></li></ul></li></ul> |
| 14:48 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cul%3E%3Cli%3E%3Cul%3E%3Cli%3E%3C/li%3E%3C/li%3E%3C/ul%3E%3C/li%3E%3C/ul%3E |
| 14:49 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cul%3E1%3Cli%3E2%3Cul%3E3%3Cli%3E4%3C/li%3E5%3C/li%3E6%3C/ul%3E7%3C/li%3E8%3C/ul%3E might be more useful |
| 14:49 | <sirPalook> | ops! maybe i have an old version. |
| 14:50 | <sirPalook> | sorry for the noise. |
| 14:50 | <zcorpan_> | no worries :) |
| 16:21 | <met_> | see for the first time, that google suggest you other results http://www.google.com/search?q=html%205 - after three "html 5" results google suggest me "html 4" results |
| 16:23 | <zcorpan_> | met_: that has been so for some time i think |
| 17:21 | <Philip`> | Hmm, does IE not support iframe.onload? |
| 17:34 | <Philip`> | http://canvex.lazyilluminati.com/misc/dom-viewer/ -- half live + half dead = zombie? |
| 17:34 | <Philip`> | http://canvex.lazyilluminati.com/misc/dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Co%3Ap%3E%3Ca%20b%3D - IE, FF and Opera all do different things on each side |
| 17:36 | <Lachy> | I've done some more thinking about the design principles and revised my suggestions a bit (see yesterday's discussion http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-66 ) |
| 17:36 | <Lachy> | I think we need to reword Don't Reinvent the Wheel and Pave the Cowpaths |
| 17:36 | <Lachy> | these are my new suggestions: ... |
| 17:37 | <Lachy> | Don't Reinvent the Wheel: Evaluate the success and failure of existing solutions. For those that have proven reasonably successful in terms of benefits, usage and implementation, consider adopting, retaining and/or improving upon them in preference to dismissing and inventing new features. |
| 17:37 | <Lachy> | Pave the Cowpaths: Investigate existing practices and design or adopt features that meet the desires of authors. Where possible, solutions should leverage the existing techniques and skill sets of authors which will help promote the adoption of new features. |
| 17:39 | <Lachy> | I'm going to mail them to the list shortly, any suggestions before I do? |
| 17:39 | <othermaciej> | Lachy: please do mail the list |
| 17:44 | <Whiskey_M> | both admirable, but I wouldn't rule out fresh invention where appropriate. Take for example the DVD, if cow paths were followed we'd just have video recorders with faster rewinds / skips and greater media protection. I know there is a time and place for innovation thus I guess the most important word is *appropriate* - just my 2p worth ;-) |
| 17:45 | <Lachy> | Whiskey_M: that's a perfect example of misunderstanding and inappropriately applying the principle |
| 17:46 | <Whiskey_M> | fair enough, although I might not be the only one to get the wrong end of the stick then |
| 17:46 | <Lachy> | DVDs solve a significant problem that video tapes had with their quality |
| 17:46 | <othermaciej> | Whiskey_M: the original intent of the principles was: |
| 17:48 | <othermaciej> | Don't Reinvent the Wheel -- if there's a deployed solution in existing implementations (i.e. web browsers) to some problem, then even if it has some quirks and minor problems it is likely to be a better choice than something brand new, and effort is probably better spent on improving it than making up something new |
| 17:48 | <Lachy> | but if you want to apply pave the cowpaths to DVD and VHS, then you would look at how users are already familiar with inserting media into a player and pressing play, seeking, etc. e.g. tapes, CDs, records, etc. So DVDs to leverage that existing skill set |
| 17:49 | <othermaciej> | Pave the Cowpaths -- if authors are doing something that is harmless but either forbidden or not explicitly encouraged, it might be a good idea to allow or even encourage it, because if conformance imposes pointless requirements then authors won't do it |
| 17:50 | <othermaciej> | neither of these principles would be very applicable to inventing a brand new format |
| 17:50 | <othermaciej> | as opposed to making a new version of an existing one |
| 17:50 | <othermaciej> | DVD is not VHS5 |
| 17:50 | <Whiskey_M> | thanks macie :-) Lachy ok, bad analogy |
| 17:51 | <othermaciej> | in both cases you need to do some investigation to see what problems are being addressed, whether the de facto solution is a good one, etc |
| 17:52 | <othermaciej> | this is why all the principles are written in a hedged way ("might", "consider", etc) and not as absolute commandments |
| 17:52 | <othermaciej> | it is a balancing act |
| 17:53 | <Lachy> | yes, that's why I've tried to emphasize the necessity of research in the proposed wordings |
| 17:55 | <Philip`> | What are the alternative viewpoints that "don't reinvent the wheel" is opposed to? Is the problem when people just ignore existing implementations entirely, or is it when they actively want to avoid any relation with existing implementations (i.e. implementations of a feature are seen as a negative point)? |
| 17:55 | <Philip`> | (or both?) |
| 17:56 | <Philip`> | (or something else? but presumably there's at least some kind of alternative viewpoint, because otherwise it's just a pointless obvious statement rather than a design principle that's helpful when making decisions) |
| 17:58 | <othermaciej> | Philip`: there's been some active opposition voiced to "Don't Reinvent the Wheel"; the idea is that we can invent better solutions if we start with a blank slate, than if we have to accept the legacy issues of an existing solution |
| 17:58 | <Lachy> | Philip`: pave the cowpaths tends to get conflated with reinventing the wheel and the objection is that it's seen as a way to block the introduction of new features. I think the best example of this would be the in the discussion of the role attribute |
| 17:59 | <othermaciej> | for example, some might propose that instead of <canvas> we should have a whole different approach to immediate-mode graphics that is perhaps somehow part of SVG |
| 17:59 | <othermaciej> | or that instead of contentEditable we should invent a whole new editing API that seems more elegant |
| 18:00 | <othermaciej> | obviously it is a matter of balance (no one has proposed adopting IE's support for namespaces in HTML for instance), but some thing that existing de facto implementations should be given no weight at all |
| 18:01 | <Lachy> | IIRC, some people have even compared it with introducing CSS for layout when tables were already in use for that purpose, and then using that as a strawman to object to it |
| 18:01 | <othermaciej> | a similar line of argument has been used to argue against "Support Existing Content" - that we can make something better and "fix the web" if we break compatibility |
| 18:01 | <hsivonen> | othermaciej: actually, discussion Re: namespaces has come pretty close to adopting what IE does |
| 18:02 | <Lachy> | crap! I don't want to adopt what IE does for namespaces :-( |
| 18:03 | <hsivonen> | I'm on a PPC Mac, so I'm not personally in a good position research IE's behavior. I'm hoping that MS or Opera would share their experiences on this. |
| 18:03 | <Philip`> | I thought IE looked almost sensible, but that's just because I was using the Live DOM Viewer which gives incorrect answers |
| 18:04 | <Philip`> | (like http://canvex.lazyilluminati.com/misc/dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Co%3Ap%3E%0D%0A%3Chtml%20xmlns%3Ao%3E%0D%0A%3Co%3Ap%3E has "p > p" on the left, "O:P + p" on the right) |
| 18:05 | <Lachy> | in IE, <foo:bar>...</foo:bar> is parsed as pseudo-XML, rather than as ordinary unknown tags. The major problem with it is that it also creates it's typical broken DOM with badly nested elements |
| 18:06 | <Lachy> | so some special variation of the adoption agency algorithm would need to be developed for it |
| 18:06 | <othermaciej> | is there a lot of legacy content depending on details of IE's parsing for namespaces in HTML? |
| 18:07 | <Lachy> | sadly, there's a lot of XForms in tag-soup on the web |
| 18:07 | <Lachy> | and probably MathML too |
| 18:07 | <Lachy> | thanks in part to applications like FormsPlayer and MathPlayer (or whatever they're called) |
| 18:08 | <Philip`> | It's (generally) only parsed as pseudo-XML if you have a <html xmlns:foo> before it, and not if you use document.write, and people do use document.write with IE namespaces, which probably makes it painful to reproduce |
| 18:08 | <hsivonen> | Lachy: aren't you taking the purist attitude instead of paving the cowpaths there? ;-) |
| 18:09 | <Philip`> | There's loads of <o:p> and quite a bit of VML, but I don't know if people care how that's parsed or how it interacts with the DOM |
| 18:09 | <othermaciej> | if IE's implementation would be hard to emulate enough to be interoperable then I guess it is better to have syntax which won't collide with it instead |
| 18:10 | <Lachy> | hsivonen, possibly :-) |
| 18:10 | <Philip`> | ("loads" = more than 1% of pages) |
| 18:11 | <Lachy> | well, actually, I don't object to adding support for MathML and SVG in HTML, but I just the existing solution of using pseudo-XML syntax in HTML is more harmful, and thus it is a case where a better solution should be developed |
| 18:13 | <hsivonen> | Lachy: just adding SVG and MathML isn't the kind of distributed extensibility Sam called for |
| 18:13 | <Lachy> | I don't understand Sam's use cases for adding it. |
| 18:14 | <Lachy> | although I haven't read that whole thread yet. |
| 18:14 | <hsivonen> | Lachy: the cases cited thus far have been about non-browser server-side templating languages leveraging HTML5 toolchains |
| 18:14 | <Lachy> | But I think the facebook example he gave is actually a case where the authoring environment should be XML, and then serialised as HTML after processing |
| 18:15 | <hsivonen> | Lachy: well, yeah, except that XML is too hard |
| 18:16 | <Lachy> | do you really think it's too hard for the developers that FBML is targetted at? |
| 18:17 | <othermaciej> | There's really multiple reasons people have for wanting namespaces in HTML, and they don't necessarily all point to the same solution |
| 18:17 | <hsivonen> | othermaciej: agreed |
| 18:17 | <othermaciej> | 1) support for specific well-known XML vocabularies (perhaps best handled via special-casing of the root elements, but needs a good fallback story) |
| 18:18 | <hsivonen> | Lachy: did you notice Sam's PHP spaghetti example? it has all the same problems regarding well-formedness as PHP spaghetti spewing XHTML |
| 18:18 | <Philip`> | https://secure.mysociety.org/cvstrac/fileview?f=mysociety/pb/phplib/pbfacebook.php&v=1.1 |
| 18:18 | <othermaciej> | 2) support for well-known custom tags without regard to XML compatibility but with the ability for any third party to define an extension that is not expected to be understood natively by browsers |
| 18:19 | <othermaciej> | 3) same as 2 but with the additional requirement of being able to correspond to a "namespaces in XML" infoset |
| 18:19 | <othermaciej> | (and to generate an XML namespace DOM) |
| 18:19 | <hsivonen> | othermaciej: 4) same as 3) with non-XHTML nodes |
| 18:20 | <othermaciej> | hsivonen: non-XHTML nodes? |
| 18:20 | <hsivonen> | (#3 is satisfied with all elements being in the XHTML namespace) |
| 18:20 | <othermaciej> | ah, I see, you could make custom elements in the XHTML namespace, yes |
| 18:21 | <othermaciej> | I guess my point is that the solution for #2 that has the best backward compatibility and best behavior in pre-HTML5 browsers is probably something that doesn't use XML namespaces at all |
| 18:23 | <Lachy> | hsivonen: I hadn't noticed the PHP example, but that's a problem with PHP and a good illustration of the danger of developing XML under tag soup conditions |
| 18:23 | <Philip`> | Does it matter how #2 is handled in pre-HTML5 browsers, since the extensions are (if they're like FBML) meant to be processed by the HTML5 tools on the server and are no longer present in what's served to the browser? |
| 18:24 | <hsivonen> | Philip`: Sam said he was targeting both browsers and non-browsers |
| 18:25 | <othermaciej> | it does matter if you want to serve it on the public World Wide Web |
| 18:26 | <hsivonen> | I'm not so convinced that distributed extensibility on the Web is a good idea. as opposed to extensibility by centralized clearing houses like the microformats community |
| 18:27 | <Philip`> | hsivonen: othermaciej's #2 was for things not understood by browsers, so perhaps there's room for separate browser (#1) vs non-browser (#2/#3) solutions |
| 18:28 | <othermaciej> | Philip`: I meant not natively understood by browsers with special handling; not necessarily not served to browsers |
| 18:28 | othermaciej | hopes that distinction is clear |
| 18:29 | <othermaciej> | I think IE's weird handling of unknown tags may break any hope of a backwards-compatible extension mechanism |
| 18:29 | <hsivonen> | whoa, http://hsivonen.iki.fi/producing-xml/ is almost 2 years old. (speaking of PHP and XML) |
| 18:30 | <Lachy> | I don't object to the principle of extensibility on the web, but I really think it needs to be done in a way that doesn't mess too much with the parsing. i.e. I don't think letting authors make up their own elements is a good idea |
| 18:31 | <othermaciej> | there does not seem to be a huge need for custom elements that are unknown to browsers, in publicly served content |
| 18:31 | <Lachy> | I think extension mechanisms using attributes can be successful, like microformats have used class and rel. |
| 18:32 | <othermaciej> | you would probably get better results by styling an existing semantic-free element like <span> or <div> with a class |
| 18:32 | <Lachy> | also something like role="", if it were introduced |
| 18:33 | <Philip`> | You could perhaps have UAs treat <x:y> the same way as HTML5 currently does (i.e. an element named "x:y"), except say UAs may support specific namespace prefixes (svg, math, etc) and parse them under different rules into an XML-like DOM. Then HTML5 browsers wouldn't break old content (<o:p>, <v:rect>, etc), but they could support new content (<svg:svg>), and the new content would degrade no worse than any other tag soup in IE, and non-browser tools cou |
| 18:33 | <Philip`> | ...could support their own extensions |
| 18:33 | <othermaciej> | custom attributes seem more potentially useful |
| 18:33 | <othermaciej> | for cases where you want key/value data and would rather not parse it out by hand |
| 18:33 | <gsnedders> | Philip`: having an <svg> element has already been suggested without namespaces at an HTML document level, by simply changing the namespace that the elements are put within |
| 18:34 | <othermaciej> | what's the o namespace referred to in <o:p>? |
| 18:34 | <Lachy> | I supposed we should also consider which use cases are solved by things like XBL, which can give all the practical benfits of extending the language, but without all the mess |
| 18:34 | <othermaciej> | is that a real commonly used namespace or just a popular random example? |
| 18:34 | <Philip`> | othermaciej: <o:p> is from Microsoft Office |
| 18:35 | <othermaciej> | Philip`: ewww |
| 18:35 | <Philip`> | (and it was in 1.7% of pages I looked at a while ago) |
| 18:35 | <Lachy> | Philip`: that seems a little low |
| 18:36 | <othermaciej> | Lachy: XBL+CSS lets you add new behavior and presentation, but it doesn't help you represent the custom semantics that you want to attach this styling and behavior to |
| 18:36 | <othermaciej> | Lachy: so it's kind of orthogonal |
| 18:37 | <othermaciej> | using XBL with <div class="foobar"> doesn't address any of the reasons people might want a <foobar> tag in their markup, whatever those might be |
| 18:38 | <othermaciej> | XBL also potentially creates a greater need for custom attributes |
| 18:38 | <Lachy> | hmm, I suppose, though it's not really clear what the use cases are for such extensibility on the client side |
| 18:39 | <Lachy> | if it's extensibility like microformats are doing, then their solution already works. |
| 18:40 | <Lachy> | maybe it's something like these JavaScript triggers http://www.alistapart.com/articles/scripttriggers/ |
| 18:40 | <Lachy> | basically, custom attributes to extend existing elements |
| 18:41 | <othermaciej> | it seems like XBL is more likely to increase rather than reduce the desire to send custom elements and attributes |
| 18:42 | <Lachy> | really? |
| 18:42 | <Lachy> | why? |
| 18:42 | <othermaciej> | if you make some kind of complex custom control using XBL, you'll tend to think it should be its own tag |
| 18:42 | <othermaciej> | rather than binding it to <div class="something"> |
| 19:10 | <othermaciej> | so was Molly actually just annoyed about that article anointing Zeldman as "King of Web Standards"? |
| 19:10 | <othermaciej> | is that the personal agenda she was referring to? |
| 19:20 | <Whiskey_M> | 'lo |
| 19:21 | <Lachy> | what does 'lo mean? |
| 19:21 | <Whiskey_M> | as in hello |
| 19:22 | <Lachy> | ah |
| 19:25 | <Philip`> | It's the opposite of 'hi' and therefore means the same |
| 20:01 | <met_> | http://www.molly.com/2007/08/13/dear-what-wg-and-html-5-wg/ |
| 20:09 | <othermaciej> | wow, molly sure likes all-caps boldface |
| 20:14 | <hsivonen> | hmm. having the spec on too servers seems to be perceived as a problem. but XBL is published by 2 orgs. as is RELAX NG and ODF |
| 20:15 | <hsivonen> | at least in the case of HTML 5 and XBL, the content is verbatim as opposed to ISO RELAX NG having gone through the ISO obfuscation process |
| 20:15 | <hsivonen> | s/too/two/ |
| 20:53 | <molly> | Hi all |
| 20:53 | <molly> | I've posted some clarifications as many WHAT WG members were concerned about conversation on my blog, perhaps this will help http://www.molly.com/2007/08/13/dear-what-wg-and-html-5-wg/ |
| 20:55 | <molly> | Hixie |
| 20:55 | <molly> | hsivonen |
| 20:55 | <molly> | kevinmarks |
| 20:55 | <molly> | lachy |
| 20:55 | <hasather_> | molly: s/Sevonin/Sivonen/ |
| 20:56 | <molly> | hello? |
| 20:56 | <jgraham> | molly: hello (although I am not on your list :)) |
| 20:57 | <molly> | hi jgraham |
| 20:57 | <molly> | hasather, thanks, I always do that to Henri! |
| 20:57 | <molly> | sorry Henri |
| 20:57 | <molly> | fixed no |
| 20:57 | <molly> | now |
| 20:58 | <jgraham> | One reason there are two lists dealing with HTML5 stuff is that the W3C policy prevents members of W3C-Member organisations who are not nominated representatives from providing feedback |
| 20:58 | <hasather_> | molly: now it's Sevonen which is still wrong :) |
| 20:59 | <molly> | ha! ok, fixed again. |
| 20:59 | <molly> | jgraham, that's a problem then that W3C policy needs to repair |
| 20:59 | <molly> | having two lists at two trajectories is a fragmentation |
| 21:00 | <jgraham> | I agree that the dual-list situation is not ideal. But I don't think it's more harmful than the alterntaives |
| 21:00 | <gsnedders> | then we have the issue of the time taken to change the process document |
| 21:00 | <molly> | I think it's very harmful. |
| 21:00 | <jgraham> | Why? |
| 21:01 | <jgraham> | Most discussion now happens on public-html |
| 21:01 | <molly> | which is authorotative? How is that expressed to the wider public? |
| 21:01 | <molly> | gsnedders: agree that the time issue with w3c is awful. But that's why my initial comments were explicitly not to the WHAT WG |
| 21:01 | <molly> | but to the W3C and to WaSP |
| 21:02 | <jgraham> | Neither. The spec is authoritative. public-html is authoritative in producing deliverables insofar as the W3C brand carries much more weight than the WHATWG brand |
| 21:02 | <gsnedders> | molly: but it's why we can't do anything about the issue with the W3C mailing list situation. It'd be nice if we were just allowed to use the existing mailing list. |
| 21:03 | <gsnedders> | (which to this day still has more subscribers) |
| 21:03 | <molly> | so how do we make that allowable? The W3C bears enormous responsibility in accommodating WHAT WG process as it relates to HTML 5. |
| 21:03 | <jgraham> | (or rather the HTMLWG, which conducts its business via public-html, is authoritative) |
| 21:03 | <hsivonen> | molly: hi |
| 21:03 | <molly> | Hi Henri! |
| 21:03 | <molly> | sorry to mis-spell your name so many times, I think I corrected it now :D |
| 21:03 | <hsivonen> | molly: no problem |
| 21:04 | <gsnedders> | molly: we'd have to get the W3C group re-chartered |
| 21:05 | <molly> | so what's the point of HTML 5 serialization under W3C then? |
| 21:05 | <hsivonen> | molly: I still stand by what I said earlier (not in the comments of your previous post but even earlier): HTML 5 fixes many things in HTML 4.01, but releasing merely the fixes is not a good idea as it would slow down launching new features |
| 21:05 | jgraham | doesn't really understand that question |
| 21:05 | gsnedders | doesn't either |
| 21:05 | <hsivonen> | which need to be launched to keep HTML competitive |
| 21:06 | <molly> | I understand the need and desire to keep HTML moving forward. I have no problem with that |
| 21:06 | <molly> | but I think there's an audience that people are missing |
| 21:06 | <molly> | and that's why I keep digging around this issue |
| 21:06 | <jgraham> | The point of the HTML 5 serialization compared to what? An XML serialisation? |
| 21:06 | <gsnedders> | I, in many ways, would've preferred we developed the spec separate from the W3C and just submit it when completed, thereby avoiding the entire over-bureaucracy of the W3C |
| 21:06 | <jgraham> | Compared to leaving HTML stagnant? |
| 21:06 | <molly> | and that is the fact that we don't even have stable specs implemented as is |
| 21:07 | <hsivonen> | molly: merely releasing bug fixes is not interesting enough to justify a new thing to people who don't know how important the fixes are |
| 21:07 | <molly> | no, jgraham, i didn't mean that |
| 21:07 | <molly> | I meant under w3c |
| 21:07 | <molly> | not that WHAT WG wouldn't continue its work |
| 21:07 | <molly> | but if the W3C is an impediment |
| 21:07 | <hsivonen> | molly: if anything, new exciting features are needed for marketing and the bug fixes are delivered on the side |
| 21:07 | <molly> | a detriment |
| 21:07 | <jgraham> | From who's point of view? |
| 21:07 | <molly> | well, this is all well and good but what do you say to the poor suckers of the world who still don't know what a DOCTYPE is much less why they should care? |
| 21:07 | <jgraham> | Rejoice! |
| 21:08 | <molly> | we forget how we see this versus how the rest of the world sees it |
| 21:08 | <hsivonen> | molly: I'd give them a link to my doctype page :-) |
| 21:08 | <gsnedders> | your markup will be parsed consistently! |
| 21:08 | <jgraham> | For HTML5 is designed to make your life easier |
| 21:08 | <molly> | MY life? |
| 21:08 | <jgraham> | (at least, if I can help it at all... ;)) |
| 21:08 | hsivonen | has been educating people about doctypes since 2000 |
| 21:08 | <molly> | yes, Henri, and I often to send people to you |
| 21:08 | <jgraham> | The life of people who know little about doctypes + etc. |
| 21:08 | gsnedders | once ended up doing HTML in computing at school. |
| 21:08 | <molly> | however, perhaps the magnitude of "them" |
| 21:08 | <gsnedders> | I ended up teaching the class, not the teacher |
| 21:08 | <molly> | um, these are people who work the Web today |
| 21:08 | <molly> | yes, exactly |
| 21:08 | <molly> | thank you |
| 21:09 | <molly> | now you see my pov |
| 21:09 | <molly> | I'm the educator |
| 21:09 | <molly> | that's the role I play |
| 21:09 | <molly> | I have to take this and make it make sense to people |
| 21:09 | <molly> | not only who are doing daily work |
| 21:09 | <hsivonen> | molly: the hardest part in that is this: http://annevankesteren.nl/2007/04/html-red-pill |
| 21:09 | <molly> | but who can't figure out how the fuck to implement anything as it is much less as we all see it through our various colored glasses |
| 21:09 | <jgraham> | Right, so one thing that has been happening is to simplify needness complexity |
| 21:10 | <jgraham> | like now we have <!DOCTYPE html> rather than the HTML4 cruft |
| 21:10 | <molly> | I know |
| 21:10 | <jgraham> | so it's easier to learn what a doctype is |
| 21:10 | <molly> | I'm not so sure that's true |
| 21:10 | <jgraham> | Why not? |
| 21:10 | <gsnedders> | jgraham: maybe not what it is |
| 21:10 | <jgraham> | It's a magic string... |
| 21:11 | <molly> | most of the people working on specs seem to not realize that the majority of people working in the front lines of web design and dev |
| 21:11 | <gsnedders> | a doctype is a far from simple concept |
| 21:11 | <molly> | are not trained, do not understand |
| 21:11 | <molly> | do not get exposed to the ideas |
| 21:11 | <molly> | and just do "what works" |
| 21:11 | <gsnedders> | jgraham: what's magic about it? |
| 21:11 | <hsivonen> | molly: how can we do anything if we assume no learning at all? |
| 21:11 | <jgraham> | That depends what you mean by "what" |
| 21:11 | <molly> | in fact, one of the most common questions in XHTML classes? "if elements are supposed to be lower case, why is DOCTYPE upper case?" |
| 21:11 | <jgraham> | :) |
| 21:11 | <molly> | :: bangs head on desk :: |
| 21:12 | <molly> | back to Anne's "no sgml" point |
| 21:12 | <othermaciej> | hi molly, thanks for visiting |
| 21:12 | <molly> | hi! other maciej |
| 21:12 | <molly> | are you really another maciej? |
| 21:12 | <molly> | or the one I'm familiar with? :D |
| 21:12 | <othermaciej> | probably the one you are familiar with |
| 21:12 | <hsivonen> | molly: HTML5 solves that. no more explaining XHTML-as-text/html that doesn't have an explanation that makes sense to students |
| 21:12 | <othermaciej> | but there is a different maciej on this server |
| 21:12 | gsnedders | ponders where the other comes from |
| 21:12 | <othermaciej> | damn him for stealing my name |
| 21:12 | <gsnedders> | I'm too slow, dangnamit! |
| 21:12 | <molly> | hehe |
| 21:13 | <Hixie> | molly: commented on your blog |
| 21:13 | <molly> | Hixie, hi there |
| 21:13 | <molly> | thank you! |
| 21:13 | <jgraham> | gsnedders: If the class were sufficiently competent you could explain that it's needed to turn off some odd behaviour needed for back-compat |
| 21:14 | <gsnedders> | jgraham: what's wrong with the odd behaviour? |
| 21:14 | <hsivonen> | gsnedders: odd behavior is counter-intuitive |
| 21:14 | <jgraham> | It's odd :) |
| 21:14 | <hsivonen> | gsnedders: counter-intuitive is hard |
| 21:14 | gsnedders | is trying to remember how he explained it |
| 21:14 | <Hixie> | molly: to answer your question "so what's the point of HTML 5 serialization under W3C then?", the answer is that we had to move the spec development to have it covered by the w3c's patent policy in order to get microsoft to review the spec. |
| 21:14 | <gsnedders> | hsivonen: HTML is odd regardless, though |
| 21:15 | <Philip`> | People seem to be very good at remembering <html> and <head> and <body> - what makes <!doctype html> so much harder? |
| 21:15 | <Hixie> | molly: (there were other minor benefits of having it under the w3c, but that was by far the main reason) |
| 21:15 | <molly> | Hixie, I am following the lists but part of my frustration is the volume. I will be present at the working group during the tech plenary in november |
| 21:15 | <jgraham> | Anyway molly, things like the parsing algorithm will, eventually, make things better for authors and they won't even know about it |
| 21:15 | <molly> | yes, Chris filled me in on that part |
| 21:15 | <othermaciej> | having it covered by the w3c patent policy is a benefit to all interested parties |
| 21:15 | <molly> | but there is still expressed concern over that |
| 21:16 | <Hixie> | othermaciej: indeed |
| 21:16 | <molly> | I'm not well-versed on IP/Patent issues so I really wouldn't want to comment on that |
| 21:16 | <othermaciej> | the mail volume is indeed hard to follow |
| 21:16 | <molly> | but I understand the general points |
| 21:16 | <othermaciej> | it would be good if it was easier to follow only a subset of issues, for those who have strong interest and expertise in particular areas but limited time |
| 21:16 | <othermaciej> | I'm not sure how to make that happen though |
| 21:16 | <molly> | that's a really good point maciej |
| 21:17 | <othermaciej> | having the whatwg list is good as a forum for those who are for whatever reason unwilling or unable to join the HTML WG |
| 21:17 | <Hixie> | you don't really have to follow the lists to contribute, though |
| 21:17 | <othermaciej> | but the balance of useful work continues to shift more towards the HTML WG list |
| 21:17 | <molly> | Hixie: I know, and as I said, I'll be there in person in November |
| 21:17 | <Hixie> | in the public-html list you need but send out your feedback, then write it up in the wiki according to that e-mail i sent |
| 21:17 | <Hixie> | and then it'll be taken into account |
| 21:18 | <molly> | sot hat's a good starting point for me in terms of any actual participation |
| 21:18 | <molly> | I have lots of reasons to be hesitant, as you can see |
| 21:18 | <jgraham> | The flip side is public-html probably has a poorer signal/noise than the WHATWG list still |
| 21:18 | <Hixie> | molly: i'm not sure i will, we'll see (i don't see much point to face-to-face meetings, they cost a lot in carbon offsets and they don't tend to bring the spec forward much) |
| 21:18 | <molly> | Hixie: Funny, i find it the opposite. The effort and commitment to show up, pay the way, and face each other can be very useful IMO |
| 21:19 | <gsnedders> | molly: there are plenty of people, like myself, who simply cannot afford to go to meetings for whatever reason |
| 21:19 | <molly> | I understand that gsnedders |
| 21:19 | <molly> | that's a realistic barrier that's an unfortunate one |
| 21:19 | <molly> | but we all work in different ways |
| 21:20 | <othermaciej> | face-to-face meetings can be useful on a human and community level, but are rarely an efficient way to make progress on the spec |
| 21:20 | <gsnedders> | molly: which thereby has the affect that everything has to go through the mailing lists after a real meeting |
| 21:20 | <molly> | Those here who have met me know that I'm a very personable human and enjoy the F2F work a great deal |
| 21:20 | <molly> | and benefit most from it |
| 21:20 | <othermaciej> | meeting people in person aids mutual understanding and helps soften future online disputes |
| 21:20 | <molly> | this is my feeling too, maciej |
| 21:20 | <Hixie> | othermaciej: yeah, i would be interested in an unconference style meeting, if we could get a good chunk of the group to attend (like, 50-100) |
| 21:20 | <molly> | that's what works for me |
| 21:20 | <molly> | how could something like that work? Be affordable for people and actually happen? |
| 21:20 | <molly> | I'd love to see something of that nature |
| 21:21 | <molly> | "unconference style meeting" |
| 21:21 | <Hixie> | othermaciej: i just don't want to sit around a table for 3 days while people talk about how their pet feature is a good idea but without even having explained what they're trying to solve and without any evidence |
| 21:21 | <hsivonen> | molly: I guess the big problem is where to have it: Paris, Boston or the Bay Area |
| 21:21 | <Hixie> | to support their claims |
| 21:21 | <jgraham> | hsivonen: Why one of those |
| 21:21 | <molly> | Hixie: I surely can't disagree with you on THAT! :D |
| 21:21 | <jgraham> | ? |
| 21:22 | <Hixie> | molly: i don't think i can think of a single f2f meeting i've been to that hasn't involved hours of that :-( |
| 21:22 | <othermaciej> | Hixie: I would echo your loathing of the standard w3c format |
| 21:22 | <hsivonen> | jgraham: the hot spots of Europe, East Coast and West Coast |
| 21:22 | <molly> | within the W3C format yesw |
| 21:22 | <molly> | well, Henri - we had that informal day in Paris |
| 21:22 | <molly> | something could grow from that sort of thing |
| 21:22 | <Hixie> | gotta go, bbiab |
| 21:22 | <molly> | that approach, let's say |
| 21:23 | <molly> | round table discussion external from W3C, corporate agendas |
| 21:23 | <molly> | etc. |
| 21:23 | <molly> | no one's saying any of this is easy or has a fast solution |
| 21:23 | <molly> | my real concern is what happened to WaSP |
| 21:23 | <molly> | and the failings of the W3C |
| 21:23 | <gsnedders> | less and less appears to be happening at WaSP |
| 21:23 | <molly> | to provide a fair forum and process |
| 21:24 | <jgraham> | In any case the problem is not where to have it, it's getting enough people to attend |
| 21:24 | <molly> | gsnedders: As its retired mom, you know it breaks my heart |
| 21:24 | <molly> | jgraham: maybe it has to take place in several locations and we synch up somehow |
| 21:24 | <molly> | this way it can be global and reduce the carbon concerns that Hixie pointed to |
| 21:25 | <gsnedders> | and also, most likely, get more attendees |
| 21:25 | <gsnedders> | (due to lower costs of travel, etc) |
| 21:25 | <molly> | yes |
| 21:25 | <molly> | absolutely |
| 21:25 | <hsivonen> | jgraham: exactly, the three places I mentioned probably are the best for attendance, but still people are reluctant to travel across the Atlantic or from coast to coast. so no matter what the place is, it is always wrong from some point of view |
| 21:25 | <molly> | that's why maybe several locations |
| 21:25 | <molly> | where there's onsite, linked up |
| 21:25 | <molly> | Paris, SF, etc. |
| 21:25 | <gsnedders> | (though if there's one in Paris, and it's in late Oct, maybe I'll be there :P) |
| 21:25 | <jgraham> | molly: Even if you have three locations, most people would have expenses of >£100 ($200) to attend |
| 21:26 | <jgraham> | which is a lot for people not being paid for this stuff |
| 21:26 | <molly> | hey, you're preaching to the soprano in the choir here |
| 21:26 | <molly> | I've spent a fortune in my own money |
| 21:26 | <molly> | on standards-related efforts |
| 21:26 | <molly> | believe me, I know |
| 21:26 | <gsnedders> | what about students, who simply don't have their own money to spend? |
| 21:27 | <molly> | there has to be some kind of relay |
| 21:27 | <molly> | clearly we'd be synched up |
| 21:27 | <molly> | and on IRC |
| 21:27 | <othermaciej> | maybe we could get some of the big corporations involved to provide travel stipends for at least some volunteer contributors |
| 21:27 | <molly> | and there can be some kind of moderated approach where people who could not do it F2F |
| 21:27 | <molly> | and maciej - I would be willing to knock on a lot of doors to try and get some resources for that |
| 21:28 | jgraham | should mention he is very much in favour of a f2f since it would help sort out some of the most persistent culture problems on public-html |
| 21:28 | <gsnedders> | othermaciej: end up with people screaming "I DESERVE IT MORE THAN HIM!" |
| 21:28 | <molly> | gsnedders: yes but there could be specifics put into place |
| 21:28 | <jgraham> | gsnedders: Maybe that's not a problem |
| 21:28 | <molly> | such as agreements that a sponsored participation requires an equal action (ie, involvement for a year with the group, etc.) |
| 21:28 | <othermaciej> | gsnedders: I'm not too worried about that |
| 21:28 | <molly> | neither am I to be honest |
| 21:29 | <molly> | there are ways to manage that |
| 21:29 | <jgraham> | People have to compete for funding all the time |
| 21:29 | <molly> | but I think we're on to something here |
| 21:29 | <gsnedders> | wasn't it brought up before when we last discussed a f2f on public-html? |
| 21:29 | <molly> | this would be third party |
| 21:29 | <molly> | or non party |
| 21:29 | <molly> | I should say |
| 21:29 | <jgraham> | gsnedders: Yes. I think some people didn't like it |
| 21:30 | <jgraham> | but maybe they were wrong |
| 21:30 | <molly> | in other words, this is not W3C, not WHAT WG, not WaSP, not Microsoft, Mozilla, etc. |
| 21:30 | <hsivonen> | the problem with the mountain view f2f was that it lacked any stated purpose |
| 21:30 | <jgraham> | or it was pitched in the wrong way |
| 21:30 | <molly> | well, a big plate of food for thought, I Think |
| 21:31 | <gsnedders> | arguably the state of the politeness of some is a purpose on its own, now |
| 21:31 | <molly> | yes |
| 21:31 | <molly> | yes yes yes |
| 21:32 | <molly> | but I wonder if some F2F time can help that. I mean, not just sitting around the table arguing, but gaining real insight into perspectives. That, at least for me, comes through human discourse |
| 21:32 | <molly> | that is not guided by process |
| 21:32 | <gsnedders> | molly: I think just being dumped F2F might help on its own. Plenty of people are acting far worse than you ever would offline. |
| 21:32 | <molly> | I know. I think this is why I'm so upset |
| 21:33 | <molly> | I've got long-term friends and colleagues fighting with each other |
| 21:33 | <molly> | when clearly they have common goals as well as uncommon ones |
| 21:33 | <molly> | it disturbs me very much |
| 21:33 | <molly> | to see people getting that frustrated |
| 21:33 | <jgraham> | hmm. have to go for a bit. |
| 21:33 | <molly> | I don't want to add to the frustration, I didn't realize what I was stepping in honestly |
| 21:33 | <hsivonen> | molly: tantek had insightful things to say about the culture clash |
| 21:34 | <molly> | so now I'd like to help reduce the frustration |
| 21:34 | hsivonen | looks up the URL |
| 21:34 | <molly> | yes, he and I had a long talk about it last night Henri |
| 21:34 | <molly> | I thought he made some excellent points about the various factions |
| 21:34 | <hsivonen> | http://krijnhoetmer.nl/irc-logs/whatwg/20070812#l-123 |
| 21:34 | <molly> | but that's still no excuse for what Tantek himself points out as extremely negative behavior |
| 21:35 | <molly> | not from anyone, including myself. I get frustrated too |
| 21:35 | <molly> | but the accessibility guys, for one |
| 21:35 | <molly> | that stuff has to stop |
| 21:35 | <molly> | I mean, you'll never get Joe Clark to stop |
| 21:35 | <molly> | but that's Joe |
| 21:35 | <molly> | however, there have to be some human connections made here between those factions |
| 21:36 | <molly> | or more accurately, those fractions (badumpump) ;-) |
| 21:36 | <gsnedders> | I think one thing that people need to get past is that evangelism is not enough on its own. Too many people are pretty much saying that any accessibility feature MUST NOT be removed, without any justification. |
| 21:36 | <molly> | I think removing things is part of the fear and concern over HTML 5 in general |
| 21:37 | <molly> | why do things have to be "removed" per se |
| 21:37 | <hsivonen> | it seems to me that not all "accessibility guys" are the same. and there are some who don't think HTML 5 is all bad. but I understand that they don't want to engage in the smear discussions |
| 21:37 | <gsnedders> | my posting has gone down and down the more and more this has all taken over |
| 21:37 | <gsnedders> | because there's very little real discussion happening |
| 21:37 | <molly> | yes, and that's a problem! |
| 21:37 | <molly> | signal / noise |
| 21:38 | <gsnedders> | not just that, it's that there is barely any signal at all, now |
| 21:38 | <molly> | Everyone who cares, I think, feels that |
| 21:38 | <gsnedders> | I've been posting everything bar HTML WG spec review to the WHATWG list |
| 21:40 | <hsivonen> | molly: part of the problem is that public-html is so unpleasant that the signal get routed around it (e.g. to here) |
| 21:40 | <molly> | I think I'd also like to see some status stuff |
| 21:40 | <molly> | like "these are the key points" |
| 21:40 | <hsivonen> | s/get/gets/ |
| 21:40 | <molly> | I'd help with that - but writtten for the masses |
| 21:40 | <molly> | not for the groups |
| 21:41 | <molly> | that might help cause less concern in the broader community? |
| 21:41 | <molly> | right now, that noise is frightening people |
| 21:41 | <molly> | or overwhelming them, even our best and brightest |
| 21:43 | <gsnedders> | the other interesting factoid is that as the volume of email has increased, the time taken for me to read them has gone down, simply as more and more of it is pointless and takes scarcely any time to deal with |
| 21:43 | <gsnedders> | molly: what sort of status things? |
| 21:43 | <molly> | some way of sorting through the noise |
| 21:43 | <molly> | to get to the signal |
| 21:44 | <molly> | and clarify those points on a regular basis to the broader public |
| 21:44 | <gsnedders> | so some sort of summary about what is going on? |
| 21:44 | <molly> | exactly |
| 21:44 | <gsnedders> | and do it how frequently? when needed? |
| 21:45 | <molly> | I think an update now would be great, something to provide the community at large with more insight into the signal and get the frustration level that the noise is creating down a bit |
| 21:45 | <molly> | I think another update around the Tech Plenary time would also be good |
| 21:45 | <molly> | and if needed in between |
| 21:45 | <gsnedders> | when is the Tech Plenary? |
| 21:45 | <molly> | November |
| 21:46 | <hsivonen> | molly: there's no clear WG level going on. but watching Hixie here and watching the svn commit messages gives an idea of the goings on with the spec |
| 21:46 | <molly> | http://www.w3.org/2007/11/TPAC/overview.html |
| 21:47 | <molly> | like the Twitter updates? Those are cool. But how about annotated every few weeks |
| 21:47 | <molly> | that sort of thing |
| 21:47 | <hsivonen> | molly: btw, one PR problem is that since Hixie doesn't really do firefighting in spec writing, the time it takes from an issue flaring up to the spec changing can be in the order of months |
| 21:48 | <hsivonen> | molly: so even if Hixie says here that a bad part of the spec sucks, people still keep thinking that the spec is destined to remain sucky on that point |
| 21:49 | <Hixie> | can even take years |
| 21:49 | <hsivonen> | (I think not doing firefighting is the reasonable way, but it still creates the wrong impressions sometimes) |
| 21:50 | <hsivonen> | molly: so people who don't follow along here get outraged about <font> again and again |
| 21:50 | <hsivonen> | molly: I'm here, so I just leave <font> unimplemented in the conformance checker and trust that the part will go away in due course |
| 21:50 | <Hixie> | i should go around adding red boxes to the most controversial parts |
| 21:50 | <Hixie> | that might help |
| 21:50 | <hsivonen> | Hixie: yeah |
| 21:51 | <molly> | Something of that nature, yes! |
| 21:51 | <molly> | good idea |
| 21:51 | <Hixie> | can you send a mail to me or one of the lists listing the controversial parts and suggesting i add red boxes? i'll try to do it after my next commit (the alt text revamp) |
| 21:51 | <Hixie> | i have to go get my bike fixed first |
| 21:53 | <gsnedders> | g'nite |
| 21:53 | <gsnedders> | but, molly, if you want any help to do such an update, I'm more than welcome to do so |
| 21:54 | <molly> | absolutely! |
| 21:54 | <molly> | I'd totally like to do that |
| 21:54 | <molly> | HTML 5 news capsules, like Hixie does on Twitter but with annotations |
| 21:55 | <gsnedders> | molly: I'm on here pretty much all the time (though not always physically here, but I'll read anything addressed to me), and there are other contact details listed on my blog <http://geoffers.uni.cc/the-author/>; |
| 21:56 | <gsnedders> | (that design is almost two years old. wow.) |
| 21:56 | <Hixie> | anyone should feel free to post on the WHATWG blog if they want to post regular updates |
| 21:56 | <Hixie> | in fact i highly encourage it |
| 21:57 | <Hixie> | just sign up to the blog and then post (and ask Lachy to set you up as an editor so you can actually post the entries once you've drafted them, we had to turn that off because spammers were using it) |
| 21:57 | <molly> | but see, that goes back to the issue of fractioning |
| 21:57 | <molly> | Shouldn't that really be also on the W3C? |
| 21:57 | <Hixie> | well, feel free to post on the w3c blog too :-) |
| 21:57 | <molly> | hahaha |
| 21:57 | <Hixie> | or instead :-) |
| 21:57 | <Hixie> | but you'll have to speak to DanC about that, i don't know how to post to that blog |
| 21:58 | <Hixie> | it's not an open blog like the whatwg's |
| 21:58 | <molly> | yep |
| 21:58 | <Hixie> | my point is just that you should just go ahead and do things |
| 21:58 | <molly> | Hixie, I think my track record proves I learned that one a long time ago ;-) |
| 21:59 | <molly> | however, battles must be picked carefully |
| 21:59 | <molly> | that's my concern. |
| 21:59 | <molly> | for me, personally. That's why I think WaSP has a responsibility here. |
| 21:59 | <Hixie> | well, i don't care who does the updates or where |
| 21:59 | <Hixie> | i just don't have time to edit the spec _and_ do the updates |
| 21:59 | <Hixie> | so someone else has to do it |
| 21:59 | <molly> | no of course not |
| 21:59 | <Hixie> | it can be you, or it can be someone else, that's not my problem :-) |
| 22:00 | <molly> | getting the highlighting done would be an awesome thing to help out too |
| 22:00 | <molly> | so you committed to that |
| 22:00 | <molly> | I'll commit to working with whoever here wants to work on |
| 22:00 | <molly> | summaries |
| 22:00 | <molly> | and we can cross blog 'em |
| 22:00 | <hsivonen> | also http://people.w3.org/mike/planet/html5/ |
| 22:00 | <molly> | which is the best idea to get the word out to broad communities anyway |
| 22:01 | <molly> | Henri: thanks! |
| 22:01 | <Hixie> | (i recommend starting by assuming no-one will help out, because usually people only help out once it is proven that something is happening) |
| 22:03 | <molly> | Hixie: I appreciate your kind guidance. |
| 22:03 | <molly> | I'm pretty used to herding cats. |
| 22:04 | <molly> | and occasionally effective at it, too :D |
| 22:04 | <Hixie> | :-) |
| 22:04 | <Hixie> | bbiab |
| 22:06 | <gsnedders> | molly, Hixie: IMO such a blog should be separate to both WHATWG and the W3C |
| 22:06 | <molly> | gsnedders: I think if it's just updates |
| 22:06 | <molly> | it is best in as many places as possible |
| 22:07 | <gsnedders> | I think it's both or separate. People will always conclude something wrong if it is just in one place. |
| 22:16 | <hsivonen> | molly: thanks for following up to my question |
| 22:16 | <hsivonen> | bed time now |
| 22:16 | <hsivonen> | nn |
| 22:18 | <molly> | night Henri! |
| 22:18 | <molly> | thank you |
| 22:20 | <gsnedders> | time for me to go sleep now, too (I really mean it, this time) |
| 22:32 | <molly> | night :D |
| 22:32 | <molly> | time for me to get ready for a meeting - thanks everyone. I'll be interested as to where this goes, and I shall visit again very soon |