| 00:04 | <Hixie> | should i add document.head? |
| 00:05 | <Hixie> | i think it makes sense on the long run; would it be bad to add it now? |
| 00:05 | <TabAtkins> | I think it's probably fine. I doubt many people add .head to document, unless they're specifically emulating what we're trying to do. |
| 00:06 | <TabAtkins> | (Though my opinion doesn't count for much, since I'm not an implementor.) |
| 00:13 | <Hixie> | jgraham: pimpmyspec.net is hanging doing w3c annotations |
| 00:14 | <Hixie> | oh nevermind, it unblocked |
| 02:24 | <roc> | TabAtkins: "And those compiler-failures are pretty much only relevant on tight inner loops, which you can find via profiling and spend the effort necessary to rewrite into a more efficient form." --- that is very much not true |
| 04:17 | <GPHemsley> | You can always tell when Hixie gets bored |
| 04:23 | <GPHemsley> | ;) |
| 04:54 | <Hixie> | bored? |
| 05:38 | <GPHemsley> | Hixie: Yeah, when you're bored my inbox fills up. ;) |
| 05:38 | <Hixie> | that's not when i get bored |
| 05:38 | <Hixie> | that's when i do my job |
| 05:39 | <Hixie> | quite the opposite of when i get bored in fact |
| 05:40 | <GPHemsley> | same difference :P |
| 05:44 | <Hixie> | for you maybe :-P |
| 06:10 | <Dashiva> | <div clas=ohlson> |
| 07:22 | <boblet> | does anyone know if it’s possible to change a W3 bugtracker registered user email? can’t seem to see this option… |
| 07:24 | <Hixie> | boblet: i think so, but i don't recall how |
| 07:24 | <Hixie> | i know i've changed my e-mail address in the past |
| 07:25 | <boblet> | Hixie: thanks. will keep looking. you’d think “email preferences”, but nooo… |
| 07:30 | boblet | gives up |
| 07:53 | <cedricv> | hey guys! is the webgl draft spec available somewhere? i cannot find it |
| 07:55 | <hsivonen> | cedricv: I couldn't find I last I checked. |
| 07:57 | <cedricv> | hmm weird |
| 07:58 | <hsivonen> | cedricv: the Khronos mailing lists are secret, too |
| 08:00 | <cedricv> | hmm i guess that's why some people say that the only docs available for now are the idl files in webkit / mozilla sources... |
| 08:30 | <MikeSmith> | cedricv: we're told that efforts are being made to add more public transparency to the WebGL group but so far nothing tangible seems to have happened |
| 08:30 | <Hixie> | annevk2: yt? |
| 08:31 | <Hixie> | MikeSmith: "more"? |
| 08:31 | <MikeSmith> | cedricv: it would at least help to have some kind of statement from the group about when they estimate the spec will be made available for public review, and what the public-review process is |
| 08:31 | <MikeSmith> | Hixie: I'm trying to be generous |
| 08:31 | <Hixie> | hah |
| 08:32 | <MikeSmith> | I have faith that they're eventually going to get around to doing the right thing |
| 08:33 | <Hixie> | before or after they're done? </cynic> |
| 08:33 | <cedricv> | hmm yeah that would be nice indeed... |
| 08:34 | Hixie | tries to work out how to register HTTP headers |
| 08:34 | <hsivonen> | Hixie: what header are you registering? |
| 08:37 | <Hixie> | Last-Event-ID, Ping-From, Ping-To, WebSocket-Origin, WebSocket-Protocol, WebSocket-Location |
| 08:40 | <hsivonen> | Hixie: is Last-Event-ID a new thing that Opera's impl didn't have? |
| 08:55 | <gsnedders|work> | Anyone know if there's any reason why calling DOMImplementation.createDocument with a doctype created by a different implementation doesn't throw in any browser? |
| 08:55 | <hsivonen> | gsnedders|work: not even in IE6 if you create the doctype using the XHR ActiveX thingy? |
| 08:56 | <hsivonen> | gsnedders|work: and offer it to the broweser DOM |
| 08:56 | <gsnedders|work> | hsivonen: I don't actually have IE6 here |
| 08:56 | <hsivonen> | gsnedders|work: how do you obtain different DOMImplementations? |
| 08:56 | <gsnedders|work> | hsivonen: Different documents have different DOMImplementations |
| 08:56 | <hsivonen> | really? |
| 08:57 | <hsivonen> | for security reasons? |
| 08:57 | <hsivonen> | they wrap the same implementation, though, right? |
| 08:57 | <gsnedders|work> | Hmnm, maybe that's just Web DOM Core that says that |
| 09:00 | <gsnedders|work> | According to zcorpan's copy of Web DOM Core, createDocument with, as the third argument, function(){ var bar = document.implementation.createDocument(null, null, null); return bar.implementation.createDocumentType("bar", "", ""); }() should throw |
| 09:00 | <gsnedders|work> | I guess I should just ask zcorpan. |
| 09:00 | <hsivonen> | Isn't the purpose of DOMImplementation that you can use Xerces and Crimson DOMs in the same app |
| 09:00 | <hsivonen> | but you can't mix their objects without explicit import |
| 09:00 | <gsnedders|work> | Yeah, I think |
| 09:04 | <gsnedders|work> | "WRONG_DOCUMENT_ERR: Raised if doctype has already been used with a different document or was created from a different implementation." — DOM 3 Core |
| 09:04 | <gsnedders|work> | It doesn't what it means by a "different implementation" though |
| 09:05 | <gsnedders|work> | How I've always read it is the same as you, and I can't see any way to test a web browser does that. |
| 09:06 | <gsnedders|work> | http://www.w3.org/TR/DOM-Level-3-Core/core.html#Embedded-DOM |
| 09:06 | <gsnedders|work> | hmm, does that mean HTMLDocument should give a different implementation to SVGDocument, for example? |
| 09:08 | <gsnedders|work> | hsivonen: You wouildn't happen to know why Gecko, against spec, throws NAMESPACE_ERR for createElementNS when namespaceURI is not empty and qname is? |
| 09:09 | <hsivonen> | gsnedders|work: no idea. sorry |
| 09:12 | <Hixie> | hsivonen: probably |
| 09:26 | <hsivonen> | where can I find a Web page that tris to install Chrome Frame but that doesn't require a Wave invite? |
| 09:32 | <hsivonen> | how do I see which process is causing excessive network traffic on Mac? |
| 09:34 | <Philip`> | hsivonen: http://code.google.com/chrome/chromeframe/developers_guide.html#Detecting_Google_Chrome_Frame |
| 09:34 | <Philip`> | Sounds like that's how to do the prompting |
| 09:35 | <Rik`> | hsivonen: lsof -n I think |
| 09:36 | <hsivonen> | Rik`: it seems to show all local pipes, too |
| 09:36 | <hsivonen> | should I sort them by offset and assume that the process with a huge offset is the problem? |
| 09:37 | <hsivonen> | Philip`: Thanks. I was being lazy so I didn't have to put that on my own site for testing. |
| 09:38 | <Rik`> | looking man lsof, it might be lsof -i |
| 09:39 | <Philip`> | hsivonen: Would http://software.hixie.ch/utilities/js/live-dom-viewer/saved/260 satisfy your laziness? :-) |
| 09:39 | <Philip`> | Oh, that doesn't work so well due to XSS |
| 09:48 | <annevk2> | Hixie, am now |
| 09:48 | <Hixie> | dude |
| 09:48 | <Hixie> | i'm reading 3864 |
| 09:48 | <Hixie> | but tl;dr |
| 09:49 | <annevk2> | wait, what? |
| 09:49 | <annevk2> | ah, registering headers |
| 09:50 | <Hixie> | there's really no reason the instructions for registering http headers should be longer than 40 or so lines of text |
| 09:50 | <Hixie> | but the table of contents is about 40 lines! |
| 09:50 | <annevk2> | heh |
| 09:50 | <annevk2> | I skipped to the template myself |
| 09:51 | <Hixie> | seems wise |
| 09:51 | <Hixie> | that's what i'm looking at now |
| 09:53 | <annevk2> | hsivonen, Last-ID is new |
| 09:56 | <hsivonen> | annevk2: ok |
| 10:07 | <hsivonen> | http://www.w3.org/2001/tag/2009/10/01-minutes.html is interesting |
| 10:07 | <hsivonen> | removal of document.write() is considered an item up for debate |
| 10:09 | <othermaciej> | hsivonen: well, it wouldn't be impossible to remove it from the spec, just foolish |
| 10:10 | <othermaciej> | it would be impossible to remove it from implementations - unclear if that was requested |
| 10:13 | <MikeSmith> | we should have a hall of fame for really bad Web platform (mis)features that we are now stuck with forever |
| 10:13 | <othermaciej> | man that would just be depressing |
| 10:13 | <MikeSmith> | heh |
| 10:14 | <Hixie> | isn't that called "HTML5"? |
| 10:14 | <MikeSmith> | lol |
| 10:14 | <MikeSmith> | Hixie: color-coding, man, I'm telling you |
| 10:15 | <MikeSmith> | misfeatures in pink |
| 10:15 | <othermaciej> | why would we want to color the whole spec pink? |
| 10:15 | <othermaciej> | that would be hard to read |
| 10:15 | <Hixie> | i'd be hard pressed to find anything that's widely implemented that i couldn't point out fundamental problems with |
| 10:15 | <Hixie> | even the new stuff like canvas |
| 10:15 | <othermaciej> | DanC is so sensible in those TAG minutes |
| 10:15 | <othermaciej> | I enjoy reading his lines in the minutes |
| 10:16 | <MikeSmith> | or maybe misfeatures in <blink> would be better |
| 10:17 | <othermaciej> | how about we paint misfeatures in the blood of whoever first implemented them |
| 10:17 | othermaciej | wonders how many pints he'd have to donate |
| 10:20 | <gsnedders|work> | Sorry, I'm not allowed to give blood at home. |
| 10:25 | <othermaciej> | Noah is very sensible too |
| 10:38 | <Hixie> | Philip`: btw, i asked the rdfa guys at work and they said that the preview page is the same code as we use internally for snippet generation. |
| 10:44 | <Hixie> | ok, iana consideration sections for the http headers are all written up |
| 10:44 | <Hixie> | bed time now |
| 10:44 | <Hixie> | nn |
| 10:47 | <Philip`> | Hixie: Okay, good to know |
| 10:51 | annevk2 | wonders why the TAG spends so much time discussing matters such as document.write(); it's like a decade too late to have an architecture discussion on that |
| 10:58 | <MikeSmith> | annevk2: from the minutes, it seems like what they were discussing it in the context of whether it would be worthwhile to have a separate spec that documented HTML processing minus the bad stuff |
| 10:59 | <Philip`> | You mean an empty document? |
| 11:00 | <annevk2> | MikeSmith, could publish an empty document |
| 11:00 | <MikeSmith> | heh |
| 11:00 | <MikeSmith> | I think in a better world it would be a great thing |
| 11:01 | <annevk2> | I wonder why they waste so much time trying to understand HTML5 by brainstorming with each other while a few questions to the HTML WG list would work as well |
| 11:07 | <othermaciej> | indeed, they seem to think it may be valuable to suggest making a separate spec that is a "clean subset", or perhaps just a description in the main spec itself of what such a subset could be |
| 11:07 | <othermaciej> | timbl thought it was as simple as not using document.write() and avoiding implicit <tbody> |
| 11:07 | <othermaciej> | it would be interesting to document the intersection of HTML and XML that results in identical processing, but quite challenging |
| 11:08 | <annevk2> | you fail at <html xmlns |
| 11:08 | <annevk2> | as someone pointed out recently |
| 11:09 | <jgraham> | That does seem to be an unusually subtle issue to trap the unwary indeed |
| 11:09 | <jgraham> | I guess there is some value in documenting the intersection that gives the minimum achievable difference between HTML and XML processing |
| 11:15 | <othermaciej> | annevk2: fair enough - it couldn't be identical, it would have to be some definition of "close enough" processing |
| 11:15 | <othermaciej> | annevk2: which would be hard to define in itself |
| 11:15 | <othermaciej> | you'd also have to rule out all use of script if you want the subset to be statically checkable |
| 11:17 | <annevk2> | and CSS |
| 11:17 | <annevk2> | e.g. html[xmlns] { background:papayawhip } |
| 11:19 | <csarven> | Is or was there anything in the talks of doing something along the line of <input type="rememberme">? It would be a checkbox, but it would work similar to type="password" where the default behaviour of the UA will fill in i.e., remember me in login forms by default or not |
| 11:20 | <hsivonen> | did the Super Friends ever follow up with Sam on the polyglot stuff? |
| 11:20 | <jgraham> | annevk2: That seems like it is about observability not static checkability |
| 11:20 | <MikeSmith> | csarven: autocomplete? |
| 11:21 | <jgraham> | hsivonen: I don't recall anything from them except the individual emails sent bu Jeremy Keith and tantek |
| 11:21 | <hsivonen> | jgraham: I don't recall emails on polyglottal issues |
| 11:22 | <hsivonen> | jgraham: I do recall adactio sending other email |
| 11:22 | <jgraham> | hsivonen: Yes that was what I meant |
| 11:22 | <jgraham> | (sorry for being unclear) |
| 11:23 | <csarven> | MikeSmith I guess that'd be it. <input type="checkbox" autocomplete="on">. But autocomplete doesn't appear to apply checkbox. Would this be a good case to do so? The only problem is that, the UA doesn't know it is about 'rememberme' |
| 11:23 | <hsivonen> | I guess I'll proceed to zapping the new menu from V.nu if the Super Friends aren't going to follow up with Sam |
| 11:24 | <MikeSmith> | csarven: it might be worth proposing in a e-mail to one of the mailing lists or through W3C bugzilla |
| 11:24 | <gsnedders|work> | http: doesn't match URI-reference, right? |
| 11:25 | <csarven> | MikeSmith Thanks, I could do that, but, I wanted some quick feedback on it before going ahead. There may have been discussions around that already. |
| 11:26 | <annevk2> | remembering is a UI feature |
| 11:26 | <annevk2> | autocomplete can be used to turn things off, on is not really a meaningful value |
| 11:29 | <csarven> | annevk2 So, what you are saying is that <input type="checkbox" autocomplete="on"> would be sufficient? |
| 11:57 | <annevk2> | no |
| 11:58 | <annevk2> | Hixie, the title attribute for the set-cookie header is wrong, you made it http-setcookie2 |
| 11:58 | <annevk2> | Hixie, not sure if it affects anythings |
| 12:33 | <gsnedders|work> | Hixie: You got any idea why I'm not getting any whatwg email to gsnedders@op? |
| 12:37 | <Philip`> | gsnedders|work: Maybe you're not subscribed |
| 12:37 | <gsnedders|work> | Philip`: I was before, but I tried filling out the form… didn't even get confirmatioin email |
| 12:48 | <mpt> | Argh |
| 12:49 | <hsivonen> | mpt: ? |
| 12:50 | <mpt> | I've wandered into one of those places where people still think draconian error handling for a markup language targeted primarily at humans is a good idea |
| 12:50 | <hsivonen> | what place is that? |
| 12:50 | <mpt> | http://mail.gnome.org/archives/gnome-doc-list/2009-October/msg00014.html |
| 12:52 | mpt | wonders about the most productive way to reply |
| 12:53 | <annevk2> | mu |
| 12:53 | <hsivonen> | mpt: is Gnome practicing decentralized extensibility and minting stuff like <demo>? |
| 12:53 | <mpt> | haha |
| 12:54 | <mpt> | Hm, now you're making me think what it would be in non-extensible HTML |
| 12:55 | <mpt> | Probably something like <a href="demo:%20awkwardly-escaped%20script%20goes%20here"> |
| 12:56 | <mpt> | with the demo: protocol restricted to access only from ghelp: URLs |
| 13:01 | <othermaciej> | generally when you find yourself making a new markup language, you're probably doing it wrong |
| 13:01 | <gsnedders|work> | Blatantly we should just use triple stores, SPARQL, and transform everything to HTML. |
| 13:02 | <othermaciej> | mpt: is it true that feed readers ignore well-formedness for Atom? (I knew that was true for RSS) |
| 13:02 | <gsnedders|work> | othermaciej: They use the same parser |
| 13:03 | <gsnedders|work> | othermaciej: It's not that they ignore well-formedness completely, normally, though |
| 13:03 | <othermaciej> | I'm wondering if maybe Safari's (well, PubSub's) Atom implementation might use real XML parsing |
| 13:03 | <othermaciej> | I know the RSS implementation is very... generous |
| 13:04 | <gsnedders|work> | othermaciej: You still need to ignore invalid byte sequences, but otherwise you get away with it fine in Atom |
| 13:04 | <othermaciej> | of course, real standalone feed readers completely ignore the MIME type so they'd have to use a single parser |
| 13:04 | <othermaciej> | (even if that parser just does some sniffing and then switches) |
| 13:04 | <gsnedders|work> | zcorpan: http://krijnhoetmer.nl/irc-logs/whatwg/20091006#l-217 |
| 13:04 | <othermaciej> | (and people bitch about the sniffing browsers do...) |
| 13:05 | <gsnedders|work> | othermaciej: SimplePie at least just uses a real XML parser for everything |
| 13:06 | <hsivonen> | othermaciej: my recollection of hearsay is that Safari doesn't treat encoding errors as fatal |
| 13:06 | <mpt> | othermaciej, I see that the Universal Feed Parser accepts non-well-formed XML <http://www.feedparser.org/docs/bozo.html>;, but I haven't done an actual survey |
| 13:06 | <othermaciej> | I remember doing some experiments once where I got Apache to serve an RSS feed with the Atom mime type and the Atom feed with an RSS MIME type |
| 13:06 | <mpt> | othermaciej, non-well-formed Atom, I mean |
| 13:06 | <gsnedders|work> | mpt: That uses an XML parser and falls back to a custom one |
| 13:06 | <othermaciej> | (and of course it worked fine everywhere) |
| 13:07 | <gsnedders|work> | othermaciej: SimplePie forks based upon the root element. I don't think you do actually need to support those two mixed up, it's more supporting application/xml and text/xml feeds. |
| 13:07 | <gsnedders|work> | othermaciej: Oh, the other spec you have to break for Atom compat. is RFC3023 |
| 13:08 | <othermaciej> | gsnedders|work: break which aspect? the text/xml encoding lie? |
| 13:08 | <gsnedders|work> | othermaciej: yeah |
| 13:08 | <othermaciej> | right, I don't think you need them mixed up, was just experimenting to determine the extent of sniffing |
| 13:09 | <othermaciej> | I was able to serve both feed types as each other, as text/html, as image/jpeg, as image/svg+xml, as application/pdf, and of course all of those worked in every feed reader I could find |
| 13:09 | <othermaciej> | I did not, at the time, try introducing well-formedness errors |
| 13:10 | <othermaciej> | it's sad that feed readers handle bogus Atom, when one purpose of Atom was supposed to be to make a clean break from all that |
| 13:11 | <gsnedders|work> | othermaciej: Basically you establish a document is a feed, and use the same code-path thereon |
| 13:11 | <othermaciej> | (I should mention that not all those types worked in feed readers built into browsers of course; they would fail on types that don't get sniffed for feeds) |
| 13:12 | <othermaciej> | but of course the fact that feed readers ignore Content-Type is what requires you to sniff for feeds in the first placr |
| 13:12 | <othermaciej> | *place |
| 13:12 | <gsnedders|work> | SimplePie rejects any feed not served as application/rss+xml, application/atom+xml, application/xml, application/rdf+xml, text/xml, or text/html (with HTML5-heristics) |
| 13:13 | <gsnedders|work> | We've got very, very, very few bug reports from not supporting more. The only one that used to come up a fair bit was text/plain, but since Firefox and Safari stopped sniffing that that has almost totally vanished. |
| 13:14 | <gsnedders|work> | The number of bug reports from unescaped ampersands far exceeds MIME-type issues. |
| 13:14 | <othermaciej> | that is omewhat encouraging |
| 13:14 | <gsnedders|work> | And from memory most of the XML well-formedness issues are in RSS feeds, not Atom ones. |
| 13:15 | <gsnedders|work> | Atom, as I said before, you have to allow invalid byte sequences, but I think that's the only real concession you have to make for compatibility |
| 13:16 | <gsnedders|work> | (and this is something with millions of deployed copies, and as far as I can tell we've reached the point where increasing marketshare has more or less stopped causing such a dramatic increase in broken things being found, so that is probably representative of the feed landscape in general) |
| 13:20 | <gsnedders|work> | The number of cases of unescaped ampersands, which AFAIK is the cause of 90% or so of well-formedness errors (excluding invalid byte sequences, which are the most common), is certainly decreasing. I made the decision two/three years ago to stop supporting such feeds in SimplePie, and the number of bug reports we're getting on them is going down over time, quite clearly. |
| 13:22 | <jgraham> | Maybe people are just not bothering to file bugs on you anymore since you wontfixed all the other bugs |
| 13:22 | <gsnedders|work> | (I decided to remove support primarily because we don't have our own XML parser: having one in PHP would be ungodly slow, so anything to special case certain errors is quite hackish, and this was causing some compat. issues with certain combinations of (valid) things (Atom + XHTML content + CDATA, IIRC), so I took the decision to favour the valid) |
| 13:22 | <gsnedders|work> | jgraham: Maybe, but there are still plenty of other duplicates we get filed :) |
| 13:23 | <gsnedders|work> | I am fairly certain from what I've seen elsewhere (e.g., what rubys has posted on his blog of stats from feed validator) that the state of feeds is getting better. |
| 13:24 | <gsnedders|work> | I'd say it is a realistic thing to change to using an XML (+NS) parser that allows invalid byte sequences and ignores RFC3023 (for text/xml charset) |
| 13:24 | <gsnedders|work> | </soapbox> |
| 13:34 | <jgraham> | http://www.youtube.com/watch?v=yFYH9BCRPAw |
| 13:56 | GPHemsley | is getting tired of the <cite> argument |
| 14:11 | <Philip`> | GPHemsley: Is it not endlessly fascinating? |
| 15:18 | gsnedders|work | guesses that IE's DOM-like thing has to have protection to stop XPath causing infinite loops. |
| 15:25 | <Philip`> | gsnedders|work: I know nothing about this, but: Isn't XPath just supported in XML, where presumably IE uses MSXML which has a real DOM and is completely independent of the IE's HTML DOM-like thing? |
| 15:26 | <gsnedders|work> | Philip`: XPath is supported in HTML too |
| 15:27 | <Philip`> | Oh, okay |
| 15:53 | <gsnedders|work> | Philip`: Oh, I'm wrong |
| 16:29 | <gsnedders|work> | Anyone got any idea about what the best way to count the descendants of a document is? |
| 16:29 | <gsnedders|work> | (pref. in a way that works in IE) |
| 16:29 | <jgraham> | It is important to clarify that you mean "Nodes" |
| 16:31 | <zcorpan> | just c/p from live dom viewer |
| 16:31 | <zcorpan> | and don't count the red nodes |
| 16:31 | <jgraham> | (but the short answer is "walk the 'tree' being careful to not count any node twice or descend into the descendants of nodes that you have seen before" |
| 16:31 | <jgraham> | ) |
| 17:10 | <jgraham> | Where does HTML5 say normatively that event handler attributes are null in the absence of being defined |
| 17:10 | <jgraham> | I can see where it says they are null if the content attribute doesn't compile |
| 17:10 | <jgraham> | or if the IDL attribute is removed |
| 17:11 | <jgraham> | Oh, nevermind it was obvious |
| 17:12 | <jgraham> | (just in the paragraph above where I was looking) |
| 17:13 | <GPHemsley> | Philip`: No, actually, it's endlessly repetitive. |
| 17:17 | <gsnedders|work> | http://www.betanews.com/article/Yahoo-Apple-Adobe-others-named-in-Eolas-patent-lawsuit-blitz/1254842259 |
| 17:20 | <tantek> | ah the ghost of patent trolls past raises its ugly head |
| 17:23 | <Philip`> | We should all be glad that their innovation allowed us to have interactive plugins embedded in web pages |
| 17:24 | <Philip`> | Surely it's fair that they deserve a billion dollars for that? |
| 17:28 | <Dashiva> | And patents don't have any chinese wall equivalent either, do they? |
| 17:28 | <Dashiva> | Even if you didn't know about the patent, you're infringing someone else's innovation |
| 17:30 | <Philip`> | Indeed, otherwise it'd be trivial to steal someone's legitimate patent and just pretend you never read about it, which would be pretty much impossible to disprove |
| 17:33 | <tantek> | I wonder if history will repeat or not. |
| 17:33 | <cardona507> | hello - there was a really great video that went around the public_html mailing list last week about HTML5 and what it can do and how well it is supported in the different browsers. I am pretty sure it was made by someone at google. I can't seem to locate it in my email. Can someone point me toward it? (I apologize if the description is kinda vague) |
| 17:34 | <cardona507> | I want to post it to my HTML/CSS class forum |
| 17:34 | <tantek> | Last time, various folks (including TBL) wrote friend of the court briefs outlining how the so called "innovations" were previously openly discussed - by others - on w3.org mailing lists. But that didn't seem to affect the outcome. |
| 17:34 | <webben> | cardona507: http://vimeo.com/6691519 ? |
| 17:35 | <cardona507> | webben - exactly :) thanks |
| 18:04 | <gsnedders|work> | Philip`: yt? |
| 18:06 | <Philip`> | gsnedders|work: Y |
| 18:06 | <gsnedders|work> | Philip`: What pages contain: document.createElement(["']< |
| 18:07 | <Philip`> | gsnedders|work: Do you mean document\.createElement\(["']< ? |
| 18:07 | <gsnedders|work> | Philip`: yeah |
| 18:08 | <Philip`> | gsnedders|work: Ask me again in five minutes |
| 18:12 | <gsnedders|work> | Philip`: again? |
| 18:14 | <Philip`> | gsnedders|work: http://philip.html5.org/data/createelement-with-angle-bracket.txt |
| 18:15 | <gsnedders|work> | Philip`: thx |
| 19:47 | GPHemsley | shifts uncomfortably after reading the latest response in the <cite> debate. |
| 19:50 | <TabAtkins> | GPHemsley: To be fair, I totally agree with him, and don't understand quite how it could be misconstrued as badly as it is by Hixie. |
| 19:51 | <GPHemsley> | I'm personally of the belief that <cite> should be used to mark up an entire entry in a bibliography, so I don't even bother getting directly involved in the discussion. |
| 19:51 | <GPHemsley> | But yeah, I certainly don't agree that <cite> should be restricted to just titles of works |
| 19:51 | <TabAtkins> | Interesting, but totally against legacy usage, so can be struck immediately. ^_^ |
| 19:52 | <GPHemsley> | Precisely :P |
| 19:52 | <TabAtkins> | Yeah, I just added an example from my own site to the whatwg wiki page about it. |
| 19:52 | <TabAtkins> | As I use the <blockquote>/<cite> pair to mark up testimonials, and expect to continue to do so in the future. |
| 19:53 | <GPHemsley> | right |
| 19:53 | <GPHemsley> | what is the link to the wiki article, please? |
| 19:53 | <TabAtkins> | One sec. |
| 19:55 | <TabAtkins> | GPHemsley: http://wiki.whatwg.org/wiki/Cite_element |
| 19:55 | <GPHemsley> | thanks |
| 19:58 | <GPHemsley> | perhaps we should analyze the word 'cite' itself? |
| 19:58 | <GPHemsley> | if so, the first question is, are we using it as a verb or a noun? |
| 19:59 | <TabAtkins> | I use it as a verb. I'm citing whatever's in the <cite>. |
| 20:01 | <GPHemsley> | hmm... according to the main definition of the verb 'cite', it cane be used to refer to quotes/quotations, titles, and people |
| 20:01 | <GPHemsley> | s/cane/can/ |
| 20:02 | <TabAtkins> | Yeah, the first one doesn't jive with legacy <cite>, but the second and third definitely do. |
| 20:03 | <TabAtkins> | Which is why I don't understand why Hixie keeps splitting things the way he does. We want to use <cite> for "things we cite". He seems to be slicing things differently - he wants to use for "x things", making sure that x is a category that can be reliably styled as a citation. |
| 20:03 | <TabAtkins> | Which is why names don't work for his logic - most of the time you *don't* want to mark up a name, or style it with italics. |
| 20:03 | <GPHemsley> | reading the FAQ entry on it, it seems that the main issue is the difference in styling (i.e. italics) between titles and authors |
| 20:04 | <TabAtkins> | I just don't see a significant difference, though. I italicize cited names. |
| 20:04 | <TabAtkins> | And if I was bolding them or something, I'd be bolding work names too. |
| 20:05 | <GPHemsley> | I think <cite> should be used for things such as parenthetical citations or footnotes (e.g. in spec documents, like <cite>[RFC3066]</cite>), rather than any off-handed mention of a work's title |
| 20:06 | <TabAtkins> | Basically I just don't want to be stuck with <span class=cite> when I'm trying to mark up names being attributed for styling purposes when there's a perfectly serviceable <cite> element right here. |
| 20:06 | <GPHemsley> | ...or author, for that matter |
| 20:06 | <TabAtkins> | Well, you *do* often style works, even if you're not directly quoting them. |
| 20:06 | <GPHemsley> | yes |
| 20:06 | <GPHemsley> | that is true |
| 20:06 | <GPHemsley> | but I think that should be dealt with separately |
| 20:07 | <TabAtkins> | And saying that "too bad, that's not *enough* quotation to get special <cite> styling, off to <span>-land with you" is weird and would just cause problems. |
| 20:07 | <TabAtkins> | A simpler rule is "are you citing something, and do you want it styled specially?". |
| 20:07 | <GPHemsley> | I think you'd be better off with <cite class="title"> and <cite class="author"> |
| 20:07 | <TabAtkins> | Possibly, if you need to slice things that thinly. |
| 20:07 | <GPHemsley> | right |
| 20:08 | <GPHemsley> | so, leave the default styling as italics (for legacy issues), and then allow any reference to any work or author, with the granularity decided by the author |
| 20:08 | <TabAtkins> | My rule for semantics is that if I can't explain it in terms of a single easy question, it's too complicated. |
| 20:08 | <TabAtkins> | Yeah, that's about what I want. |
| 20:08 | <GPHemsley> | seems simple enough |
| 20:09 | <GPHemsley> | Hixie: ^^ |
| 20:13 | <TabAtkins> | Ah, spending some time just sitting down and styling a page is so relaxing. |
| 20:15 | <GPHemsley> | heh |
| 20:15 | <GPHemsley> | while you're at it, I'd recommend to changing -- to em dashes ;) |
| 20:15 | <GPHemsley> | s/to/you/ |
| 20:16 | <TabAtkins> | Yeah, probably. I always forget how to do unicode in the content property, though. |
| 20:16 | <GPHemsley> | \u2014 |
| 20:16 | <GPHemsley> | I think |
| 20:17 | <TabAtkins> | Lemme try. One sec. |
| 20:18 | <TabAtkins> | Nope. >_< |
| 20:19 | <GPHemsley> | you did it wrong :P |
| 20:19 | <TabAtkins> | I've done it four different ways now. |
| 20:19 | <GPHemsley> | oh |
| 20:19 | <GPHemsley> | meh |
| 20:19 | <GPHemsley> | hang on |
| 20:19 | <GPHemsley> | oh |
| 20:19 | <GPHemsley> | \2014 |
| 20:20 | <TabAtkins> | Ah, excellent. |
| 20:20 | <GPHemsley> | weird... the space disappeared |
| 20:21 | <TabAtkins> | Yeah, but I don't care enough to debug. It's good enough. |
| 20:22 | <GPHemsley> | perhaps you want a \00A0 (NBSP) or \2002 (en space) \2003 (em space) |
| 20:23 | <GPHemsley> | (there's an "or" missing in there) |
| 20:25 | <tantek> | TabAtkins - re: cite element, perhaps add your voice of support to the opinions section on the wiki: http://wiki.whatwg.org/wiki/Cite_element |
| 20:25 | <tantek> | (and add any examples you have on the web as well) |
| 20:25 | <TabAtkins> | tantek: I already added an example - it's the Go Figure one. |
| 20:25 | <tantek> | oh cool - awesome |
| 20:25 | <TabAtkins> | GPHemsley: Yeah, an nbsp did it. |
| 20:26 | <GPHemsley> | TabAtkins: Cool |
| 20:26 | <TabAtkins> | Odd that it would lose an ordinary space, though. Hmm. |
| 20:26 | <GPHemsley> | TabAtkins: Incidently, I'd recommend indenting those lines just a tad, as well. |
| 20:26 | <tantek> | TabAtkins, GPHemsley, still worth adding a +1 here IMHO: http://wiki.whatwg.org/wiki/Cite_element#opinions |
| 20:26 | <TabAtkins> | Oh, the cite lines? |
| 20:26 | <GPHemsley> | yeah |
| 20:27 | <tantek> | if any strawpoll is conducted in the wg, it can include the opinions there in absentia |
| 20:27 | <GPHemsley> | what are we +1ing, though? |
| 20:28 | <tantek> | the use of the cite element to mark up names of speakers/people for quotations |
| 20:28 | <TabAtkins> | tantek: done |
| 20:29 | <TabAtkins> | GPHemsley: You're right, that looks better. |
| 20:29 | <GPHemsley> | :) |
| 20:29 | <GPHemsley> | TabAtkins: And perhaps a little extra space above, too |
| 20:30 | <TabAtkins> | above the cite or above the blockquote? |
| 20:30 | <GPHemsley> | above the cite |
| 20:30 | <GPHemsley> | (hmm... thanks for alerting to me to the 'text-indent' property, BTW) |
| 20:30 | GPHemsley | really cannot type. |
| 20:30 | <TabAtkins> | Heh, np. |
| 20:31 | <GPHemsley> | yeah, that's better |
| 20:31 | <TabAtkins> | Okay, .25em is a bit too much. I like the space, but want only a very fine one. |
| 20:31 | <TabAtkins> | Ah, better. |
| 20:32 | <TabAtkins> | .15em it is. I still want a very strong visual correlation with the preceding blockquote. |
| 20:32 | <GPHemsley> | right |
| 20:33 | <GPHemsley> | I'm gonna write a message to the cite thread regarding our discussion, BTW |
| 20:33 | <TabAtkins> | kk. That saves me having to do so. |
| 20:36 | <TabAtkins> | lunch - be back in 2 hours |
| 20:44 | <GPHemsley> | sent |
| 20:46 | <GPHemsley> | tantek: I'm now on record with what I support. Still not sure whether that fits into that +1 list. |
| 20:47 | <tantek> | GPHemsley - the beginning of the section describes what is proposed |
| 20:47 | <tantek> | http://wiki.whatwg.org/wiki/Cite_element#speaker |
| 20:47 | <GPHemsley> | Yeah, I'm there |
| 20:47 | <GPHemsley> | it's kind of a dinky sentence |
| 20:48 | <GPHemsley> | it should probably be propped up with more direct wording, like "we all support this, that, and the other thing" |
| 20:48 | <GPHemsley> | IDK, just my opinion |
| 20:48 | <GPHemsley> | easy to miss |
| 20:49 | <tantek> | ok |
| 20:49 | Philip` | adds a -1, just to balance things out |
| 20:50 | <GPHemsley> | :P |
| 20:53 | <Dashiva> | Philip`: Make it -10 just in case |
| 20:55 | <tantek> | Philip` - I encourage you to add your opinion to the wiki, along with links to any supporting materials: http://wiki.whatwg.org/wiki/Cite_element#opinions |
| 20:55 | <tantek> | GPHemsley - reload that link - I've added a summary opinion sentence to address the issue you raised |
| 20:59 | <GPHemsley> | tantek: That's better, but it's still a little submissive and ambiguous. It should make clear what +1 means versus -1. |
| 21:04 | <Philip`> | tantek: Oh, I don't want to bother actually reading the page or having an informed opinion |
| 23:32 | <TabAtkins> | Goddammit, the lack of <di> or ::di strikes again! |
| 23:34 | TabAtkins | now has to rewrite his <dl> into a <ul> with headings and paragraphs, just to get it styled in a sane way. |
| 23:35 | <TabAtkins> | Actually, I'll rewrite it as <section>s. |
| 23:43 | <TabAtkins> | Huh. I've got a weird rendering issue using figure and dt/dd in Firefox. Dunno what's causing it, but if anyone wants to troubleshoot it with me in case it's something we need to worry about on the list, let me know. |
| 23:47 | <erlehmann> | TabAtkins, i liek figure. |
| 23:47 | <TabAtkins> | Wait, never mind. I forgot to make <figure> display:block, so it was generating borders around empty line-boxes before and after its normal content. |
| 23:47 | <erlehmann> | TabAtkins, tellme. |
| 23:47 | <erlehmann> | lol |
| 23:47 | <erlehmann> | TabAtkins, line-boxes ? |
| 23:48 | <TabAtkins> | CSS term. an inline element with block contents will still generate an anonymous inline block before and after the block contents. |
| 23:49 | <TabAtkins> | (Or rather, I think the collapsed whitespace between the element's start tag and the content element's start tag (similarly for end tags) causes it.) |
| 23:49 | <Hixie> | gsnedders|work: i replied to your e-mail (saying that i had no ideas), so if you don't get it, that could be indicative of a further problem |