| 02:48 | <faure> | hi all, when I try to use the parser in html5lib I get a deprecation warning for inputstream.py, am I doing soemthing wrong? |
| 06:59 | <GPHemsley> | Can <p> be used in <li> in HTML5? |
| 07:00 | <Hixie> | yes |
| 07:00 | <GPHemsley> | cool |
| 07:02 | <GPHemsley> | is <dl>/<dt>/<dd> appropriate for a title and a description? |
| 07:03 | <Hixie> | i'd need more information to answer |
| 07:03 | <GPHemsley> | I'm making a list of links (titles) with descriptions |
| 07:03 | <GPHemsley> | and I'm trying to figure out the best way to mark it up |
| 07:04 | <Hixie> | a list of links with descriptions would work well with <dl>, yes |
| 07:04 | <GPHemsley> | should I use individual <dl>s within <li>s, or just use one <dl> for the whole list? |
| 07:04 | <Hixie> | one <dl>, if i'm understanding what you said right |
| 07:05 | <GPHemsley> | Hixie: http://gphemsley.org/blogs.php |
| 07:05 | <GPHemsley> | right now it's just links |
| 07:05 | <GPHemsley> | but I want to put a description under each link |
| 07:08 | <faure> | hi |
| 07:08 | <GPHemsley> | hi |
| 07:09 | <Hixie> | GPHemsley: <dl> seems appropriate |
| 07:09 | <GPHemsley> | one long one? |
| 07:10 | <Hixie> | yeah |
| 07:12 | <GPHemsley> | I'm noticing I'm not very creative when it comes to naming by blogs... |
| 07:14 | <GPHemsley> | s/by/my/ |
| 07:48 | <jgraham> | faure: The deprecation warning should be fixed in the latest trunk, but if you are intended in use the BeautifulSoup backend that is broken |
| 07:48 | <jgraham> | But the deprecation warning isn't very harmful |
| 08:01 | <hsivonen> | wow. An MS rep posting to a W3C mailing list is a news item at C|Net |
| 08:03 | <Lachy> | hsivonen, it also hit slashdot |
| 08:20 | <Lachy> | I think having 2 separate drafts simultaneoulsy published as official WDs (Hixie's and Manu's drafts) is going to be a PR disaster |
| 08:22 | <Lachy> | also, the W3C's publishing system isn't really designed to be able to fork specs into almost identical, but competing documents. |
| 08:26 | <hsivonen> | The payload of Manu's draft is a warning about microdata. The rest is just the delivery device. |
| 08:27 | <Hixie> | indeed |
| 08:27 | <Lachy> | hsivonen, yes, I know. That was clear as soon as I saw the microdata warning |
| 08:28 | <othermaciej> | I haven't even read the microdata warning |
| 08:28 | <othermaciej> | Lachy: you should say you object to the idea of publishing 2 WDs then |
| 08:29 | <othermaciej> | Lachy: if we publish both, I wonder how we decide which goes at http://w3.org/TR/html5 |
| 08:30 | <othermaciej> | it's kind of a silly vote, but it's pretty much a silly cote, but it's exactly what Sam asked for by soliciting technical objections to a Working Draft |
| 08:30 | <Lachy> | othermaciej, I'm considering it. I'm just trying to work out how to most effectively express my disagreement |
| 08:31 | <Hixie> | i don't really see much value in a version of the draft with just warnings added, personally |
| 08:31 | <Hixie> | i mean, we have SO MANY open issues |
| 08:31 | <hsivonen> | othermaciej: I haven't yet read the microdata warning, either |
| 08:31 | <Hixie> | thousands fewer than we did a year ago |
| 08:31 | <Hixie> | but still many |
| 08:31 | <othermaciej> | Lachy: Sam just asked for a reason - I think "separate drafts simultaneoulsy published as official WDs (Hixie's and Manu's drafts) is going to be a PR disaster" is a valid reason |
| 08:31 | <othermaciej> | Hixie: we do have some that, at least from the HTML WG's perspective, have been open a crazy long time |
| 08:32 | <Hixie> | depends on your definition of "open" |
| 08:32 | <othermaciej> | Hixie: it might be worthwhile to flag those somewhere, to highlight the fact that the Chairs are not emptying this list |
| 08:32 | <Hixie> | the ones in the issue tracker are mostly issues i've considered closed for a long time, and are only still open because the chairs aren't doing their job |
| 08:32 | <othermaciej> | I mean open in the sense that there's an open ISSUE that the chairs do not agree to close |
| 08:33 | <othermaciej> | I guess I should collect a list of controversial issues open more than 6 months |
| 08:34 | <othermaciej> | and then I could make the much shorter list of issues that were open that long, and then closed |
| 08:35 | <Hixie> | you mean issues in the issue tracker? |
| 08:35 | <Hixie> | or actual issues |
| 08:36 | <othermaciej> | I'm not sure what you mean by "actual issues" |
| 08:37 | <Lachy> | wtf? Manu's first reason for his objection to the garbage collection section is... |
| 08:37 | <Lachy> | "It seems to provide normative implementation advice" |
| 08:37 | <othermaciej> | my intent is to list issues where it seems a number of people are dissatisfied with the spec, and the chairs have not yet declared it resolved |
| 08:37 | <Hixie> | othermaciej: things like "there's an infinite loop in the parser when you do X" |
| 08:37 | <othermaciej> | Lachy: I think he might not understand that the requirement there has an observable effect |
| 08:37 | <Lachy> | Hixie, based on that, we need to remove sections 2 through 12. |
| 08:37 | <Hixie> | othermaciej: as opposed to "i have an indeterminate objection to the general direction that this section is going in" |
| 08:38 | <othermaciej> | Hixie: issues like the former are almost never "controversial" (at least I don't recall one where that was the case) |
| 08:38 | <othermaciej> | I am thinking things like "missing alt should absolutely never be allowed under any circumstances, not even if alt text is unavailable, or a <legend> or title attribute has the relevant info" |
| 08:39 | <othermaciej> | I don't really agree with that position, but it seems concrete enough to be actionable |
| 08:39 | <Hixie> | othermaciej: i don't consider such dogmatic statements to be issues, since they don't have reasoning or research. And issues with only reasoning and research are rarely controversial. |
| 08:39 | <Hixie> | if ever |
| 08:41 | <othermaciej> | Hixie: whatever you want to call them, our one Chair who does any Chairing considers them to be open issues that block consensus and prevent going to Last Call |
| 08:41 | <Hixie> | indeed |
| 08:42 | <othermaciej> | Hixie: by W3C technicality, he is right that if he doesn't either declare consensus or hold a vote then there is no WG decision |
| 08:43 | <annevk42> | I checked out that warnings draft the other day... wtf |
| 08:43 | <othermaciej> | so I would like to make the list of things where that hasn't happened yet, despite the issue being raised a long time ago |
| 08:43 | <annevk42> | the discussion on public-html is even worse |
| 08:43 | <annevk42> | there's now a side discussion whether the warnings are in the right place lol |
| 08:43 | <othermaciej> | not because I think it indicates technical problem with the spec, but because it indicates a process problem with the WG if we never close them |
| 08:44 | <Hixie> | othermaciej: i certainly don't oppose pointing out the complete lack of progress that the HTMLWG has made |
| 08:45 | <othermaciej> | Hixie: that's pretty much my point |
| 08:46 | <annevk42> | also, what's up with this crazy idea of dispatching on a subdomain rather than scheme? especially since it's part of an API call that only deals with non-HTTP... |
| 08:47 | <othermaciej> | wait, what? |
| 08:48 | <annevk42> | http://lists.w3.org/Archives/Public/uri/2009Aug/0013.html |
| 08:48 | <annevk42> | I think that guy might be a TAG member even o_O |
| 08:51 | <othermaciej> | O_o |
| 08:54 | <annevk42> | http://lists.w3.org/Archives/Public/uri/2009Aug/0005.html was the original email btw |
| 08:56 | <othermaciej> | reading his actual paper is even scarier http://dbooth.org/2006/urn2http/ |
| 09:08 | <Lachy> | Hixie, in http://www.whatwg.org/specs/web-apps/current-work/#focusable why is the list item "area elements that have an href attribute" marked with class="XXX"? |
| 09:09 | <Lachy> | oh, I see, there's a comment in the source about it |
| 09:09 | <Lachy> | nevermind |
| 09:09 | <annevk2> | area is tricky |
| 09:16 | <Hixie> | not really sure what to do about <area> and focus |
| 09:16 | <Hixie> | but i really should fix that soon |
| 09:16 | <othermaciej> | do browsers let you tab-cycle through the <area>s of an image map? |
| 09:18 | <Hixie> | the problem is that image maps can be used with multiple images |
| 09:18 | <Hixie> | so an <area> corresponds to multiple distinct areas that have different places in tab order |
| 09:19 | <Hixie> | yet there's a single .focus() method, etc |
| 09:19 | <Lachy> | why is that a problem? |
| 09:20 | <annevk2> | what will be focused? |
| 09:20 | <Lachy> | oh, right |
| 09:20 | <annevk2> | doh |
| 09:20 | <Lachy> | I misread and throught he was talking about the onfocus event, not the focus method |
| 09:20 | <Lachy> | I should wake up better and have some breakfast |
| 09:20 | <annevk2> | not a bad idea |
| 09:21 | <annevk2> | image maps are so ancient and pretty much obsolete... |
| 09:21 | <othermaciej> | they are being considered as part of a solution to canvas accessibility |
| 09:22 | <othermaciej> | (ARIA + <area> is the buzzword) |
| 09:23 | <othermaciej> | I think Hixie just proved that the focus state cannot consist solely of an element if imagemap areas need to be focusable |
| 09:24 | <Lachy> | <area> is too limited for the use cases that people actually want image-map-like behaviour |
| 09:25 | <othermaciej> | that is probably true |
| 09:28 | <annevk2> | e.g. it fails at hover effects |
| 09:28 | <Lachy> | often, people want hover effects to apply to the hovered area, or custom popup text (like flickr), custom borders around the areas, etc. |
| 11:29 | <gsnedders|work> | Hixie: yt? |
| 11:31 | <Lachy> | When did the cite attribute get added to <section> and <article> and what problem is the pubdate attribute on <article> solving? |
| 11:31 | <hsivonen> | https://bugs.webkit.org/show_bug.cgi?id=3905#c7 |
| 11:31 | <hsivonen> | whoa! did the spec have reparsing at some point? |
| 11:32 | <Lachy> | I didn't think it did |
| 11:33 | <Lachy> | anyway, the pubdate and cite attributes seem to violate the general principle of avoiding hidden metadata |
| 11:33 | <Lachy> | and it seems they were already solved by <time> and <a href><cite>, respectively |
| 11:36 | <jgraham> | Lachy: http://html5.org/tools/web-apps-tracker?from=3068&to=3069 |
| 11:36 | <jgraham> | I agree that they are pointless and silly |
| 11:36 | <hsivonen> | pubdate? |
| 11:37 | <Lachy> | hsivonen, see #the-article-element |
| 11:37 | <hsivonen> | are there known to be CDATA elements in the wild where there are multiple <!-- ... --> escape runs? |
| 11:37 | <Lachy> | I mean #attr-article-pubdate |
| 11:38 | <hsivonen> | seems very anti-patterny |
| 11:38 | <jgraham> | It came from Chaals |
| 11:38 | <Lachy> | d'oh |
| 11:38 | <hsivonen> | jgraham: but why? |
| 11:38 | <jgraham> | Specifically from "Chaals could improve the Opera intranet if he had a mechanism for identifying the original source of various parts of a page |
| 11:38 | <jgraham> | " |
| 11:39 | <hsivonen> | jgraham: wasn't that cite? |
| 11:39 | <jgraham> | Doesn't seem like anything that needs interoperable semantics |
| 11:39 | <hsivonen> | the pubdate thing smells like Atom |
| 11:39 | <jgraham> | hsivonen: Yeah |
| 11:39 | <Lachy> | so let's find a way to more semantically attach <time> and <cite> elements to a specific section, rather than adding redundant hidden metadata |
| 11:39 | <jgraham> | Dunno about pubdate |
| 11:40 | <jgraham> | hsivonen: http://html5.org/tools/web-apps-tracker?from=3115&to=3116 |
| 11:40 | <hsivonen> | hmm. I wonder if // <!-- is used in JS in the wild |
| 11:40 | <Lachy> | hsivonen, yes, I believe it is |
| 11:41 | <jgraham> | pubdate seems bad too |
| 11:42 | <jgraham> | Not sure how to fix it exatly but there should just be a way to associate <time> with a section |
| 11:42 | <jgraham> | cite I would happily drop entirely |
| 11:42 | <jgraham> | @cite thaat is |
| 11:43 | <jgraham> | Well the cite element too if it came to it but thta isn't going to happen :) |
| 11:44 | <hsivonen> | so it seems that chaals didn't ask for cite specifically, but Hixie decided that cite would address chaals' use case |
| 11:45 | <Lachy> | <time for="#section-id"> or maybe have keywords like <time for="_section"> which would link it with its most recent ancestor sectioning element |
| 11:46 | <jgraham> | Lachy: For example. Although the idref solution has all the typical idref problems of non-locality |
| 11:46 | <Lachy> | I thought cite was already on the chopping block for it's failure to adequately address the blockquote use case, so I don't understand why it was considered to be a good solution for this |
| 11:46 | <Lachy> | what do you mean by problems of non-locality? |
| 11:47 | <Lachy> | do you mean in cases where the time element has no other relationship with the element? Like when it's located elsewhere in the document and doesn't point to an ancestor or very nearby sibling? |
| 11:47 | <jgraham> | Lachy: The authour has to keep two pieces of information in sync that are not necessarily close to each other in the document source. |
| 11:47 | <Lachy> | ok |
| 11:48 | <jgraham> | Plus the problem that it can point to something nonsensical |
| 11:48 | <Lachy> | yeah, that's true |
| 11:49 | <Lachy> | and unlike with <label for>, there wouldn't be any indication at all of an error being present |
| 11:49 | <jgraham> | (the advantage of <time role=pubdate> (ergh) is that the semantics are well defined; it applies to the nearest sectioning element) |
| 11:50 | <Lachy> | is role=pubdate already defined somewhere, or are you suggesting that as a possible solution? |
| 11:50 | <jgraham> | No I'm suggesting it |
| 11:50 | <Lachy> | ok |
| 11:50 | <jgraham> | But not using role really |
| 11:51 | <jgraham> | It just seemed like a good english word |
| 11:51 | <Lachy> | conceptually, it seems like a reasonable idea |
| 11:52 | <hsivonen> | whether it's reasonable depends on whether it's worthwhile to overlay the semantics of Atom over an HTML page at this point in time in the post-RSS world |
| 12:12 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=509009 |
| 12:13 | <hsivonen> | maybe we should do the magic escape thing only for script and style |
| 12:13 | <hsivonen> | or maybe only for script |
| 12:13 | hsivonen | wonders if anyone ever uses "</style>" in generated content |
| 12:24 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E%3C!--%3C%2Ftitle%3Ea%3C%2Ftitle%3E--%3E%3C%2Ftitle%3E |
| 12:25 | <hsivonen> | very sad in WebKit |
| 12:27 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/201 is sad in WebKit, too |
| 12:28 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/202 is even worse in IE8 |
| 12:30 | <gsnedders|work> | hsivonen: With the first of those I get the same in Chromium Linux nightly as I do in Opera 10 and Minefield |
| 12:31 | <hsivonen> | gsnedders|work: what html5.enable setting in Minefield? |
| 12:31 | <gsnedders|work> | true |
| 12:31 | <hsivonen> | interesting |
| 12:32 | <hsivonen> | gsnedders|work: oops. sorry. |
| 12:32 | <hsivonen> | the point with the first one is to show that the CDATA escapes apply in WebKit when it doesn't reparse |
| 12:33 | <hsivonen> | so yeah, it's expected that the first case looks the same across browsers |
| 12:57 | <jgraham> | hsivonen: BTW I am very unhappy about the idea of adding some heuristics for guessing what mught be a js string to the parser |
| 12:57 | <jgraham> | I expect it to be a large amount of complexity for something that works very poorly |
| 12:58 | <jgraham> | I would rather have some form of reparsing if there is too much content to break since browsers are clearly willing to ship that already |
| 12:58 | <hsivonen> | jgraham: do you have non-reparsing suggestions for dealing with both "<!--" and "</script>" string literals in a Web-compatible way? |
| 12:58 | <jgraham> | hsivonen: No :( |
| 12:58 | <jgraham> | I will think about it more though |
| 12:59 | <hsivonen> | this reparsing stuff is very sad |
| 12:59 | <hsivonen> | I wonder if it is a result of accidental ad hoc parser writing or deliberate "helpfulness" |
| 13:00 | gsnedders|work | spent a bit thinking about it earlier |
| 13:00 | gsnedders|work | didn't have any idea though |
| 13:00 | <jgraham> | hsivonen: Could you make a wiki page documenting the full set of constraints i.e. everything that needs to work |
| 13:01 | <hsivonen> | jgraham: sure |
| 13:01 | <jgraham> | s/constraints/known constraints/ for gsnedders' benefit |
| 13:22 | <Philip`> | Is JS string detection much more complex than having a small state machine with outside-literal, inside-single-quoted-string, inside-double-quoted-string, inside-regexp, after-backslash? (or something a bit like that) |
| 13:22 | <Philip`> | Oh, and two inside-comments |
| 13:24 | <Lachy> | damn, I didn't expect my mail to be another opportunity for the RDFa proponents to jump in with their overly complex solution :-( |
| 13:25 | <jgraham> | Well they can both be replaced by Microdata too. |
| 13:25 | <Philip`> | They can both be replaced by English too |
| 13:25 | <jgraham> | IS English machine readable? I assume that is the point... |
| 13:26 | <gsnedders|work> | Well, to some extent… |
| 13:26 | <Lachy> | it depends if the machine readability is an essential property of the solution |
| 13:27 | <Philip`> | Depends on whether consciousness is mechanical |
| 13:27 | <Lachy> | I'm not convinved it is for either cite or pubdate |
| 13:27 | <jgraham> | Lachy: For the use case of performing an automatic conversion of html to the atom model it is |
| 13:27 | <Philip`> | but I assume that's not a philosophical debate we want to have |
| 13:28 | <hsivonen> | Philip`: on the face of it, it seems you'd need a state machine that knows about //, line break, /*, */, " and ' |
| 13:28 | <Lachy> | jgraham, that depends if HTML alone will be used as the only input to the system that generates Atom |
| 13:28 | <jgraham> | In any case it's reassuring that a technology designed to allow arbitary microdata to be embedded can be used to embed simple instances of microdata. It is disappointing that in the case of RDFa it is so complex |
| 13:29 | <Lachy> | jgraham, most CMSs seem to have enough data already to be able to generate appropriate Atom feeds, without needing the extra info to be added into the document itself |
| 13:29 | <jgraham> | Lachy: Generating feeds from pure HTML is the whole use case |
| 13:30 | <Lachy> | which kind of systems would want to do that though? |
| 13:30 | <jgraham> | The idea is that there are situations where it is too burdensome to generate multiple representations of a resource |
| 13:30 | <Philip`> | hsivonen: You need to handle var x = /[\/"]/ too |
| 13:30 | <jgraham> | And that even where it is possible it is more likely to lead to undetected bugs and so on |
| 13:30 | <Philip`> | You could use the HTTP Last-Modified date of the HTML document |
| 13:30 | <Lachy> | Is the idea to be able to subscribe to a feed in a newsreader, just like I do with Atom and RSS today, but where the actual feed is the HTML document? |
| 13:30 | <Philip`> | (Maybe you can't actually, I don't know) |
| 13:31 | <Lachy> | I don't think Last-Modified is reliable enough to be used in practice |
| 13:31 | <jgraham> | Lachy: Yes |
| 13:31 | <Lachy> | isn't that what hAtom was supposed to do? |
| 13:31 | <Philip`> | Lachy: That wheel needs reinventing |
| 13:32 | <jgraham> | Lachy: Microformats are also more complex than pure HTML |
| 13:32 | <tantek> | jgraham - perhaps compound microformats are more complex than some HTML. |
| 13:33 | <Lachy> | jgraham, you have to compare the complexity of HTML+Microformats with HTML+Microdata and HTML+RDFa |
| 13:33 | <tantek> | elemental microformats are as simple as any other rel attribute value |
| 13:34 | <tantek> | jgraham - but your point is well taken. there are several simplification improvements currently slated both for 1.0.1 versions of hCard, hCalendar etc. (existing well established compound microformats), and patterns for any future microformats. |
| 13:35 | <jgraham> | Lachy: I only need to compare the complexity of HTML with the features needed for atom to HTML + {some microdata language} |
| 13:37 | jgraham | wants a javascript tokenizer |
| 13:39 | <jgraham> | + dammit |
| 13:39 | <Lachy> | tantek, re this http://wiki.whatwg.org/wiki/Template:Cc-public-domain-release - There was a breif time when the whole wiki was in the public domain. Though I got some complaints and it had to use the MIT license, which is close enough for all practical purposes |
| 13:39 | jgraham | prefers MIT |
| 13:40 | gsnedders|work | prefers Stanford |
| 13:40 | <Lachy> | why? |
| 13:40 | <tantek> | Lachy, PD is well established (per that template) on both Wikipedia, and microformats.org. |
| 13:40 | <tantek> | in the context of wikis/content - the PD license statement is more prevalent than MIT license. |
| 13:41 | <tantek> | anyway - just like Wikipedia, WHATWG wiki authors can add the template to their user pages if they wish to do so. (I encourage it) |
| 13:42 | <Lachy> | the problem I see with your approach is that without significant uptake, it makes it difficult to know for sure whether any given page is fully in the public domain |
| 13:42 | <tantek> | Lachy, it's an incremental thing |
| 13:42 | <Lachy> | tantek, I've never seen anyone add a template like that to their user pages. |
| 13:42 | <Lachy> | on wikipedia |
| 13:43 | <tantek> | Lachy - that's where I got the idea from, quite a few do it (because they want their contribs re-used more liberally than GFDL/CC-SA) |
| 13:43 | <Lachy> | do you have a user page on wikipeida you can show me? |
| 13:43 | <tantek> | if enough authors of a wiki add it, then you can take a vote/poll and make it the policy of the wiki moving forward, and then you incrementally cleanup pages as necessary |
| 13:44 | <tantek> | yes, one sec |
| 13:44 | <Lachy> | jgraham, what's the benefit of MIT over public domain? |
| 13:44 | <tantek> | (about 4 clicks) |
| 13:45 | <tantek> | *TONS* of users use the Wikipedia version of that PD template |
| 13:45 | <tantek> | http://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Public_domain_release |
| 13:45 | <tantek> | including myself, Mike Linksvayer, etc. |
| 13:46 | <tantek> | on microformats.org/wiki, we transitioned to PD in a few steps. first we made it voluntary with the template, then when a sufficient percentage of authors (per contributions) adopted it, we made it the policy moving forward, and the requested other authors to please consider adding it as well (for past contribs) |
| 13:46 | <hsivonen> | Philip`: yeah, regexp literals are a can of worms as an edge case |
| 13:47 | <tantek> | and then have been incrementally updating pages as necessary to move them fully into PD. |
| 13:47 | <hsivonen> | does JS allow multiline string literals? |
| 13:47 | <hsivonen> | that is, raw LF inside string literal? |
| 13:48 | <hsivonen> | Philip`: if not, one could hope that no one does document.write("...</script>"); on the same line with a regexp literal |
| 13:48 | <jgraham> | Lachy: I understand that PD is regarded as less desirable than "with a specific Free license" in some jurastictions |
| 13:48 | <hsivonen> | jgraham: is that just FUD or is there some explanation written by a Real Lawyer somewhere? |
| 13:48 | <hsivonen> | (I'm aware of the IANAL legends around the point) |
| 13:48 | <jgraham> | hsivonen: But they could easilly do /foo/;document.write |
| 13:49 | <tantek> | jgraham, I believe CC0 takes care of that, which is precisely the reason for the wording in the template that says "or any later version published by Creative Commons; with either a waiver of rights, or an assertion that no rights attach to a particular work."" |
| 13:49 | <jgraham> | hsivonen: Dunno but I recall that CC suggested not using PD in the past |
| 13:49 | <Lachy> | that seems strange since, by definition, public domain has absolutely no restrictions (beyond the moral rights imposed in some countries) |
| 13:49 | tantek | has had the microformats.org PD template checked by Lawrence Lessig (a lawyer), which the WHATWG wiki PD template is based on. |
| 13:50 | <jgraham> | Lachy: IIRC the question was over whether the countries allowed you to give up your "natural" rights to things that you created |
| 13:50 | <tantek> | jgraham, CC0 takes care of the i18n of PD. |
| 13:51 | <tantek> | with language as in the template "...a waiver of rights, or an assertion that no rights attach to a particular work" |
| 13:51 | jgraham | doesn't really understand the situation, in particular how anything that requires a specific document from CC can be considered public domain |
| 13:51 | <Lachy> | jgraham, copyright is not a natural right |
| 13:51 | <jgraham> | In the absence of that understanding MIT seems safer |
| 13:53 | <hsivonen> | Lachy: depends on whether you believe in Anglo copyright or French Droit d'auteur |
| 13:54 | <hsivonen> | (I think the English basis of copyright makes sense and the French basis is empirically bullshit) |
| 13:54 | <Lachy> | I don't know what the french basis is |
| 13:54 | <tantek> | jgraham, book publishers understand PD better than MIT |
| 13:56 | <hsivonen> | Lachy: not about money but about the author's artistic relationship with the work basically |
| 13:56 | <hsivonen> | Lachy: but empirically, it still boils down to money |
| 16:03 | <adactio> | Quick question: how would you define the difference between HTML5 and HTML 5? (i.e. no space vs. with space) |
| 16:05 | <gsnedders|work> | adactio: Some people use HTML5 to refer to the text/html serialization and HTML 5 to refer to the spec. Other people make no distinction. The spec only defines "HTML 5". |
| 16:05 | <rubys> | In most usages, it doesn't matter. At times it is helpful to contrast HTML 5 (with a space, referring to the vocabulary) from the two concrete serializations HTML5 (quotes not required on attributes) and XHTML5 (draconian). |
| 16:06 | <rubys> | gsnedders|work: section 1.7 defines "HTML5" |
| 16:06 | <gsnedders|work> | rubys: Stop assuming I know what the spec says! :P |
| 16:08 | <tantek> | and what methodology led to distinguishing semantics (the spec/vocabulary vs. a serialization) based on a single space character? |
| 16:08 | gsnedders|work | guesses it was the fact the spec wasn't called HTML 5 until the W3C got involved |
| 16:09 | <rubys> | like all decisions at the WHATWG, I presume that it was based on data and reasoning (the way the WHATWG operates)[TM] |
| 16:09 | <tantek> | I will humbly submit that that decision was a big mistake, and submit as an example the home page of the wiki, which both inconsistently/incorrectly uses HTML5 and "HTML 5": http://wiki.whatwg.org/wiki/Main_Page |
| 16:09 | rubys | is shocked |
| 16:09 | <tantek> | rubys - you're better than that - no need for snark |
| 16:10 | rubys | chuckles |
| 16:10 | <tantek> | so is it true the W3C decided to call the spec "HTML 5" then? |
| 16:11 | rubys | checking |
| 16:11 | <rubys> | HTML 4.01 is called "HTML 4.01" |
| 16:11 | <gsnedders|work> | tantek: yes |
| 16:12 | <gsnedders|work> | (As it was Web Applications 1.0 before) |
| 16:12 | <rubys> | http://lists.w3.org/Archives/Public/public-html/2007May/0909.html |
| 16:12 | <tantek> | so therefore this apparent "decision" to use a whitespace character to distinguish a semantic was nothing but an accident of politics then. |
| 16:12 | <gsnedders|work> | 909!? |
| 16:13 | <rubys> | it is not clear to me the topic of to include a space or not to include a space was actually discussed. |
| 16:14 | <rubys> | That poll posed three questions, here are the first two: Shall we Adopt HTML5 as our specification text for review? Shall the W3C's next-generation HTML specification be named "HTML 5"? |
| 16:14 | <rubys> | note the inconsistent use of spaces |
| 16:14 | <rubys> | as far as I can tell, the decision and distinction is totally a WHATWG one. |
| 16:15 | jgraham | never uses the spaces consistently |
| 16:15 | <rubys> | not even in python? |
| 16:15 | <gsnedders|work> | I think it's true to say the spec was informally called HTML 5 pre-W3C |
| 16:15 | <jgraham> | I never write about HTML 5 in python :p |
| 16:16 | <gsnedders|work> | "While the HTML form of HTML5" appears in old WHATWG draft |
| 16:16 | <gsnedders|work> | But that's the only time either HTML 5 or HTML5 are used in that |
| 16:28 | <tantek> | rubys, if the distinction of "HTML5" vs. "HTML 5" came from a W3C public-html poll per that URL, how is that a "WHATWG" distinction? |
| 16:35 | <Lachy> | anyone who makes a distinction between HTML5 and HTML 5 (with/without space) as referring to the serialisation and vocabularly, respectively, is wrong. |
| 16:35 | <Lachy> | The distiction can only be made based on context |
| 16:36 | <Lachy> | or, where it's not entirely clear, by explicitly qualifying it as, e.g., "HTML5 syntax" or "HTML5 vocabularly" |
| 16:37 | <tantek> | Lachy - the spec itself tries to make such a distinction, and as such is quite confusing. |
| 16:38 | <Lachy> | the spec is wrong |
| 16:38 | <Lachy> | While it might be nice in theory to have such a distinction, in reality, we don't because we can't make people use them consistently |
| 16:39 | <Lachy> | there was a big discussion about this a year or two ago, with many people wanting to find an alternative name for it. We had all sorts of weird and wonderful suggestions |
| 16:39 | <Lachy> | like calling the serialisation "tHTML", which was short for text/html or something |
| 16:40 | <gsnedders|work> | HTML5-with-whacky-backwards-compatible-syntax-which-you-might-just-understand-if-you-do-a-backflip |
| 16:51 | <Dashiva> | There was no distinction early on, as I recall |
| 16:51 | <Dashiva> | And then someone complained that HTML 5 (or HTML5) being both the spec and a serialization was discriminating against the XHTML serialization |
| 16:54 | <rubys> | tantek: I don't believe the distinction came from a W3C poll. That poll used both terms interchangeably. Since that point, the spec (as you note) makes that distinction. I share Lachy's opinion that the spec is wrong on this totally minor and nearly irrelevant point. |
| 16:55 | <tantek> | it's not nearly irrelevant because it such a convention (using a whitespace as a semantic distinguisher) will result in much confusion (has) |
| 16:55 | <Dashiva> | In practice there's no distinction, it's just a politicial white lie |
| 16:56 | <Lachy> | well, I guess it's not really wrong. It's a useful convention for the spec to adhere too. But it's not something it can really enforce outside of the spec |
| 16:56 | Philip` | recalls similarly to Dashiva |
| 16:56 | <rubys> | tantek: if this issue is important to you, I'd suggest bugzilla |
| 16:56 | <tantek> | for example, http://twitter.com/WHATWG uses "HTML5" to refer to the spec, not the serialization |
| 16:57 | <tantek> | rubys - bugzilla is a show stopper user interface, far worse than email. |
| 16:57 | <Philip`> | Where has it caused confusion? |
| 16:57 | <rubys> | tantek: have you seen the new ability to enter bugzilla reports (ranging from typos to real issues) directly from the WHATWG version of the spec? |
| 16:58 | gsnedders|work | points over there |
| 16:58 | Philip` | tends to use terms like "the HTML 5 spec", "the text/html serialisation", "the XML serialisation" to avoid ambiguity |
| 16:59 | <Dashiva> | tantek: You can use bugzilla without using it by using the spec bug reporter? |
| 16:59 | <Dashiva> | Is that still using bugzilla |
| 17:00 | gsnedders|work | wonders what the practical difference between reporting issues in bugzilla and by email is |
| 17:01 | <tantek> | gsnedders - # of form fields. see: http://tantek.com/log/2007/02.html#d19t1813 |
| 17:02 | <gsnedders|work> | tantek: I mean from how they are dealt with |
| 17:02 | <tantek> | gsnedders - I referred specifically to UI in my statement. |
| 17:02 | <gsnedders|work> | (Not how they are reported) |
| 17:04 | <rubys> | the UI on the whatwg draft is simple. Read the document (scrolling as you do so). Spot something you aren't happy with. Type in your message. Click "Submit Review Comment". |
| 17:08 | <Dashiva> | We could save a lot of work by just putting one giant warning at the top of the spec |
| 17:08 | <Dashiva> | ... oh wait |
| 17:09 | <Philip`> | rubys: You forgot a step |
| 17:09 | <Philip`> | rubys: (Clicking on the bit you want to comment on) |
| 17:09 | <rubys> | OMG! The UI is too complicated! <ducks/> |
| 17:10 | <jgraham> | rubys: Actually I think the UI is too unintuituive at the moment |
| 17:10 | <jgraham> | It's YATOMTDP |
| 17:10 | <jgraham> | (Yet Another Thing On My To Do Pile) |
| 17:11 | gsnedders|work | wonders when jgraham is ever happy |
| 17:31 | <tantek> | rubys - the spec interactive bug/comment submission capability is quite clever. |
| 17:34 | <Philip`> | It seems to be a failure in practice, though |
| 17:34 | <Philip`> | judging by the signal/noise ratio |
| 17:40 | <Dashiva> | Philip`: As long as Someone is willing to handle the noise, it can still be seen as a gain overall |
| 17:41 | <hober> | If there were an optional email field, we could add it to the cc list on the bug created |
| 17:42 | <Philip`> | Do CC addresses not have to be registered users? |
| 17:46 | <hober> | I don't know. |
| 17:52 | Philip` | assumes it would be vulnerable to abuse otherwise |
| 18:47 | <jgraham> | So it seems that we're going to spend a bunch of cycles debating what should have a big red box in the spec |
| 18:48 | <gsnedders> | I stand by my suggestion of pink cuddly "Hello Kitty!" signs. |
| 18:49 | <jgraham> | I am totally reminded of the Hitchhiker's Guide to the Galaxy: "Most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small, green pieces of paper, which is odd, because on the whole, it wasn't the small, green pieces of paper which were unhappy." |
| 20:00 | <Lachy> | We should just put one giant red box at the top of the spec that says: ... |
| 20:01 | <Dashiva> | There have been objections to HTML5 as a whole, so it's only fair |
| 20:01 | <Lachy> | There are many people who collectively disagree with the entire content of this specification, and many others who collectively agree with the entire specification. As such, nothing in this draft is stable.. |
| 20:03 | <jgraham> | Lachy: we have text that says that. Does making it a red box make any difference? |
| 20:12 | <Lachy> | jgraham, yes. We put a big red border around the whole spec to make people happy |
| 20:27 | <Lachy> | on a more serious note, I wonder if we could address this issue by somehow linking the issues in the issue tracker from the status markers in the draft |
| 20:30 | <Dashiva> | Lachy: These "issues" in manu's draft aren't really issues in the sense of the issue tracker |
| 20:30 | <Lachy> | Dashiva, I know that, but by doing what I suggest, we guarantee that the issues tracked in both are in sync |
| 20:31 | <Lachy> | doing what Manu suggests amounts to arbitrarily inserting notes where random people disagree with something in a section |
| 20:31 | <Dashiva> | Yup |
| 20:31 | Lachy | takes a look at what it would take to add that to the annotation system |
| 20:39 | <tantek> | Lachy - your approach makes more sense to me than duplicating issue content in the spec. |
| 20:40 | <tantek> | I should say, a partial duplication of some existing issue content mixed with a bunch of new opinion content that has not been actually captured as an issue. |
| 20:52 | <Lachy> | Looks like we will need to add an <issue> element (or similar) to the XML output by status.cgi for each section, and then update status.js to include the information in the status boxes if present. |
| 20:53 | <Lachy> | Will also need to update the updateEntry function to be able to send a new status with the patch |
| 20:53 | <Lachy> | and update add something to the UI that allows issues to be recorded |
| 20:54 | <Hixie> | hm? |
| 20:54 | <rubys> | +1 to linking status to issues |
| 20:54 | <Hixie> | if we make the status boxes link to issues it'll be perennially out of date |
| 20:55 | <Hixie> | with the exception of the issues tracked on the issue tracker, the turnover rate is very high |
| 20:55 | <rubys> | if it is out of date, poke me, and I'll update |
| 20:55 | <Hixie> | you realise i go through about 500 issues a week right? |
| 20:55 | <Lachy> | if we only link them directly with the issue number, then they won't be out of date for too long |
| 20:55 | <rubys> | (I was referring to the W3C issues) |
| 20:55 | <Lachy> | since the issues in the W3C issue tracker don't get updated that frequently |
| 20:56 | <Philip`> | If people care about what W3C WDs say, then the WHATWG status boxes would have to be folded into the WD somehow |
| 20:56 | <Lachy> | besides, all it would take is a link to the issue. We don't necessarily need something in the status box itself to report on the status of the issue |
| 20:56 | <Lachy> | no-one should care what a W3C WD should say, as it's out of date by the time its published |
| 20:56 | <Hixie> | you mean the issue tracker that has such issues as "tools that can't generate <!DOCTYPE html>", which was resolved almost 9 months ago? |
| 20:57 | <Lachy> | obviously we wouldn't need to bother linking to issues that are already closed |
| 20:57 | <Hixie> | or "HTML Versioning and DOCTYPEs" that was resolved about 4 years ago? |
| 20:57 | <Lachy> | but just from the relevant sections to the open issues. Like linking the table section to ISSUE-32 (I think) |
| 20:58 | <Hixie> | the whatwg status tracker is going to track actual issues. If the W3C HTMLWG wants to track bogus non-issues that are open purely for political reasons, then the HTMLWG can do it using its own scripts on its own copy of the draft. |
| 20:58 | <Lachy> | fair enough |
| 21:04 | tantek | prefers links to issues (in whichever issue tracking system is more up to date etc.) in the spec over inline snapshots of issue text in the spec. |
| 21:07 | <Hixie> | i prefer to just resolve the issues when i get to them :-) |
| 21:08 | <tantek> | Hixie, perhaps links to unresolved emails to WHATWG list is your most up to date issue tracking system then. |
| 21:08 | <Hixie> | www.whatwg.org/issues is my issue tracking system |
| 21:09 | <tantek> | Thanks Hixie. |
| 21:14 | <Hixie> | ms2ger is awesome |
| 21:14 | <Hixie> | he basically just did 90% of the references work for me |
| 21:14 | gsnedders | wonders who ms2ger is |
| 21:15 | <Dashiva> | Your new competitor |
| 21:15 | <gsnedders> | Hixie: Did he find that there are dupes in the refs still? |
| 21:17 | <tantek> | gsnedders, according to http://wiki.whatwg.org/wiki/User:Ms2ger , he is https://secure.wikimedia.org/wikipedia/en/wiki/User:Ms2ger |
| 21:18 | <tantek> | a fairly frequent editor/contributor to Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/Special:Contributions/Ms2ger |
| 21:20 | <gsnedders> | Hixie: Like RFC2616 and HTTP |
| 21:20 | <gsnedders> | Hixie: XMLNAMES and XMLNS |
| 21:21 | <gsnedders> | Hixie: http://pastebin.ca/1524312 |
| 21:21 | <gsnedders> | tantek: ah |
| 22:50 | <sicking> | Hixie, ping |
| 22:50 | <Hixie> | gsnedders|work: yes, he did |
| 22:50 | <Hixie> | sicking: pong |
| 22:51 | <sicking> | Hixie, so it says that clearState should clear or history entries related to the current Document |
| 22:51 | <sicking> | Hixie, does that include entries created using normal <a> navigation to other frag-ids? |
| 22:52 | <sicking> | Hixie, i.e. could clearState have any effect even if pushState has never been called? |
| 22:52 | <Hixie> | it includes that, it includes URLs that come from navigating by hand, everything |
| 22:52 | <Hixie> | yes |
| 22:52 | <Hixie> | at least, per spec, iirc |
| 22:52 | <sicking> | Hixie, heh |
| 22:52 | <Hixie> | (whether that's desireable or not is a different question) |
| 22:52 | <sicking> | Hixie, is there a reason for this? I can't really think of a reason one way or another on this |
| 22:52 | <Hixie> | i honestly have no idea off the top of my head |
| 22:52 | <Hixie> | i'd need to look at it closer |
| 22:52 | <sicking> | ok |
| 22:53 | <Hixie> | send mail asking me to if you want to know for sure |
| 22:53 | <sicking> | ok, we might |
| 22:53 | <sicking> | justin lebar is pretty far into an implementation of all of this |
| 22:54 | <sicking> | the plan is to get an implementation and then unleash developers on it to see what makes sense |
| 22:55 | <Hixie> | nice |
| 22:55 | <Hixie> | feedback would be very welcome on this |
| 23:55 | <paulgendek> | hello |
| 23:55 | <paulgendek> | what is the intended use of <header> and <footer>, is header intended to be semantic for <div id="header">? or is it section headers only like <div class="main-top">, etc. it's my understanding that if <header> is used as <div id="header"> then we will have to still use id="header" to denote that it is the header for body, not header for any other sections, like <section id="content"><header> |
| 23:55 | <paulgendek> | continued: it would seem to be more semantic to have the header of a layout specified as <section id="header"> since it is the "header" section of the layout, and not specifically a header container for <body> |
| 23:55 | <paulgendek> | <section id="header">, container, sidebar, footer, etc. these are all <sections> in of a design, as we design semantic markup just as we design CSS as well |
| 23:57 | <paulgendek> | typically we have <div class="post"> and within we would have <div class="post-top"> or whatever, denoting a top/header container for a post, we could do the same for footer, so is <header> only to be used for this purpose? |
| 23:57 | <paulgendek> | as a "section header" and not the header of a design |