| 00:02 | <Hixie> | is philipj ever on IRC? |
| 00:16 | <Hixie> | afk |
| 00:30 | <Hixie> | i don't understand yecril71's change to the faq |
| 01:09 | <Hixie> | yt? |
| 01:09 | <Hixie> | er |
| 01:09 | <Hixie> | wc |
| 01:15 | <Hixie> | heycam: looks like we need three mechanisms in webidl to make enumeration things work right |
| 01:16 | <Hixie> | a mechanism to list properties that are exposed (name, value) |
| 01:16 | <Hixie> | a mechanism to list properties that aren't exposed but that can be accessed anyway (name, value) |
| 01:16 | <Hixie> | and a mechanism for how to handle setting of those properties (when present or not) |
| 01:17 | <Hixie> | and each mechanism needs a way to handle whether the IDL should override these mechanisms or be shadowed by them |
| 01:17 | <Hixie> | and we also need a way to mark the item, namedItem, etc methods as hooking into this |
| 01:19 | <othermaciej> | Hixie: I would say that WebIDL needs a way to mark up an interface as having dynamic properties; whether they show up to the "in" operator and hasOwnProperty; whether they are enumerable; and whether they take priority over IDL-defined properties or not |
| 01:20 | <othermaciej> | Hixie: I don't think it is necessary to represent at the IDL level that certain IDL interfaces do lookups against the same namespace as dynamic properties |
| 01:20 | <othermaciej> | Hixie: that can be expressed in spec prose just fine |
| 01:20 | <othermaciej> | (and sometimes there isn't even such a method) |
| 01:21 | <othermaciej> | it's kind of like the case of two properties having the same value or two methods doing the same thing; there's probably such cases, but there is no need for IDL to point them out |
| 01:21 | <othermaciej> | Hixie: I guess you also might want to express the traits I described separately for index and non-index properties |
| 01:21 | <Hixie> | i just don't want to have to say the same thing a bazillion times |
| 01:22 | <Hixie> | if i can just say "the item() method is a _foobarmagicmethod_." then that's fine too |
| 01:22 | <Hixie> | i don't care if it's in idl or prose so long as it is terse and non-redundant |
| 01:22 | <Hixie> | still means the webidl spec needs something for me :-) |
| 01:23 | <othermaciej> | Hixie: I think in prose you would define the name lookup algorithm once, and say that algorithm applies to dynamic properties, and is used by nameGetter |
| 01:24 | <Hixie> | right, i'm saying that the name lookup algorithm should be in webidl |
| 01:24 | <Hixie> | so that different specs don't need to redefine it |
| 01:24 | <othermaciej> | sorry? |
| 01:24 | <Hixie> | webidl the spec |
| 01:24 | <Hixie> | not the language |
| 01:24 | <othermaciej> | the name lookup algorithm is the thing that's specific to each object |
| 01:24 | <othermaciej> | in the sens eI was using the term |
| 01:24 | <Hixie> | oh |
| 01:24 | <Hixie> | i see what you're saying |
| 01:24 | <Hixie> | hm, yeah, maybe there's not much to specify |
| 01:25 | <othermaciej> | (and really it should be an algorithm that gives a current list of dynamic property names and values) |
| 01:25 | <Hixie> | well either way, i'm sure we can figure something out |
| 01:25 | <othermaciej> | (though namedItem and the like would use it for lookup purposes rather than listing ever) |
| 01:25 | <othermaciej> | right |
| 01:25 | <othermaciej> | it will be good to have this straight |
| 01:25 | <othermaciej> | I would like it to be possible for WebKit to use spec WebIDL directly as our IDL files with as little modification as possible |
| 01:26 | <Hixie> | that'd be nice |
| 01:26 | <othermaciej> | so I tend to think of things from that design angle |
| 01:26 | <othermaciej> | I know that is not the primary goal |
| 01:26 | <othermaciej> | but it would help validate both WebIDL itself and any spec using it that WebKit supported |
| 01:26 | <othermaciej> | if that worked out |
| 01:28 | <Hixie> | yeah |
| 02:08 | <aboodman2> | sicking: it seems like your example with relative urls would actually work. |
| 02:08 | <aboodman2> | maybe I am missing some subtle detail of how urls are resolved. |
| 02:09 | <sicking> | aboodman: the url would be resolved against google.com though, no? |
| 02:09 | <sicking> | aboodman2, rather than against example.html |
| 02:09 | <aboodman2> | it seems like it would resolve to http://docs.google.com/documents/report.doc |
| 02:09 | <sicking> | right |
| 02:10 | <aboodman2> | which is the same thing it would resolve to relative to index.html, assuming index.html was also hosted somewhere on http://docs.google.com/ |
| 02:10 | <sicking> | index.html is hosted on myserver.com |
| 02:10 | <sicking> | sorry, should have said that |
| 02:10 | <aboodman2> | cross-origin workers aren't allowed in html5 |
| 02:10 | <aboodman2> | i thought |
| 02:10 | <sicking> | cross-origin loading of js files are |
| 02:10 | <sicking> | i hope, no reason not to |
| 02:11 | <sicking> | they will execute in the security context of the loading page though |
| 02:11 | <sicking> | same as for <script> |
| 02:11 | <aboodman2> | huh |
| 02:11 | aboodman2 | consults the spec |
| 02:11 | <sicking> | i know the original spec didn't allow it, but i thought that was a bug |
| 02:12 | <sicking> | i don't see why we would disallow cross-site loading of the script file since <script> already allows it |
| 02:12 | <aboodman2> | "If the origin of the resulting absolute URL is not the same as the origin of the script that invoked the constructor, then throw a security exception." |
| 02:12 | <sicking> | bah |
| 02:12 | <sicking> | that sucks |
| 02:12 | <aboodman2> | workers aren't really the same thing as <script> tags |
| 02:12 | <aboodman2> | i think that is part of where our mental models differ |
| 02:13 | <sicking> | i agree :) |
| 02:13 | <sicking> | for dedicated workers they are very similar |
| 02:13 | <aboodman2> | workers are like pages |
| 02:13 | <sicking> | just out-of-process |
| 02:13 | <aboodman2> | importScripts() is like <script> tags |
| 02:13 | <aboodman2> | and you can't communicate with windows that you open that are in other origins |
| 02:14 | <sicking> | so i see dedicated workers as simply an out-of-process <script> |
| 02:14 | <sicking> | where you offload stuff you don't want to execute on the UI thread |
| 02:14 | <aboodman2> | yes, you see them like threads. |
| 02:14 | <aboodman2> | i am not sure how to resolve this difference in seeingness |
| 02:14 | <sicking> | i think it's a difference in use cases |
| 02:15 | <sicking> | bah, gotta take off for bus, i'll be back on in a few mins |
| 02:15 | <aboodman2> | ok |
| 02:15 | <aboodman2> | i will keep typing as i will probably have to go soon too |
| 02:16 | <sicking> | quicky first though: you had suggested that we support appCodeName way back when. Is that one really useful? everyone returns 'Mozilla' |
| 02:16 | <sicking> | heh |
| 02:16 | <aboodman2> | you mean on the navigator object that is exposed to workers? I just figured that we should support the same API that windows support. no reason to make things incompatible just for the heck of it. |
| 02:16 | <aboodman2> | there is already code that works with the navigator object. |
| 02:16 | <sicking> | windows support a loooong list |
| 02:17 | <sicking> | https://developer.mozilla.org/En/DOM/Window.navigator |
| 02:17 | <aboodman2> | right, I guess I assumed that exposing things to workers was not a lot of extra work. |
| 02:17 | <sicking> | i was hoping to not do the whole thing |
| 02:17 | <aboodman2> | it is hard to know what people are using today. |
| 02:17 | <aboodman2> | if you take a look at the code that libraries use to figure out what browser is which, it is crazy. |
| 02:18 | <aboodman2> | since everybody lies about who they are, it kind of has to be. |
| 02:18 | <sicking> | ah, i was hoping you had some data on that when you originally posted 5 of them :) |
| 02:18 | <sicking> | ok, rally taking off |
| 02:18 | <aboodman2> | ok. |
| 02:19 | <sicking> | have a good weekend |
| 03:04 | <Hixie> | the navigator.* stuff the spec now says to support only includes the ones that all the browsers support and return different things for |
| 03:04 | <Hixie> | so appCodeName isn't included |
| 03:04 | <Hixie> | (it is in fact commented out) |
| 03:04 | <Hixie> | regarding cross-origin, i don't mind allowing it if people want to allow it, in fact i'd like to know the use case for not allowing it |
| 03:07 | <aboodman2> | Hixie: in Gears, workers run in the origin they are loaded from |
| 03:07 | <aboodman2> | it's a feature. |
| 03:08 | <aboodman2> | it fills a similar role to postMessage() across iframes. But previously you said that you didn't want to bite that off immediately. |
| 03:09 | <Hixie> | ah hm yes, allowing cross-origin loads would make it confusing to know what origin to give the script execution context |
| 03:10 | <aboodman2> | maybe you could load workers across origins if you say that workers run in the caller's origin and have the caller's base URI. |
| 03:10 | <aboodman2> | but then shared workers don't work as well. |
| 03:30 | <Hixie> | i guess we could allow importScripts() cross-origin then |
| 03:30 | <Hixie> | without allowing workers themselves |
| 03:36 | <aboodman2> | that seems reasonable |
| 08:33 | <yecril71> | My edit to <http://wiki.whatwg.org/index.php?title=FAQ&oldid=3433#Should_I_top-post_or_reply_inline.3F>; was intentional. |
| 08:34 | <yecril71> | I have explained it at <http://wiki.whatwg.org/wiki/Talk:FAQ>;. |
| 08:36 | <yecril71> | The URL "/documents/report.doc" is local absolute. |
| 08:36 | <yecril71> | It will not cause the worker to load the wrong document. |
| 08:53 | <Hish> | hi, can anybody help me with a line height issue? <p style="font-size:36pt;">abc<span style="font-size:10pt;"> some long text </span></p> results in a paragraph with a line height of 36pt even in the lines which should only have 10pt. this happens in xhtml 5 as well as html 5. html 4 transitional works fine. |
| 08:56 | <yecril71> | I might be able to, although not on this channel. |
| 08:58 | <Hish> | yecril71: what other channel? |
| 08:59 | <yecril71> | What do you mean by "in html 5"? |
| 09:00 | <Hish> | when I set the doctype to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">; it looks fine and when I set it to <!DOCTYPE HTML> I have this problem. |
| 09:01 | <Hish> | and I assumed that <!DOCTYPE HTML> is used for html 5. isn't it? |
| 09:01 | <yecril71> | Not that way. HTML 5 uses it, but the rendering engine cannot infer it is HTML 5 from it. |
| 09:02 | <yecril71> | HTML 5 does not have a way to name its version. |
| 09:02 | <Hish> | ok. then maybe I'm wrong here. thx |
| 09:19 | <yecril71> | "pixel float" is a state of pixels that float. |
| 09:19 | <yecril71> | So "pixelfloat" for video aspect ratio is rather comical. |
| 10:45 | <Philip`> | Hish: What browser(s) do you see that behaviour in? |
| 10:46 | <Philip`> | Hish: Firefox 3 seems to do 36pt spacing with both <!DOCTYPE HTML> and <!...that html4/strict one...> (but does narrower spacing if it's in quirks mode if you don't give any doctype at all) |
| 10:46 | <Hish> | firefox, safari opera. in opera you can fix it when the outer tag is a span instead of a p |
| 10:47 | <Hish> | firefox only displays is correctly with html4 loos dtd |
| 10:48 | <Hish> | but I need xhtml to display inline svg |
| 10:48 | <Hish> | also I don't give a great future to html 4 loose |
| 10:48 | <Philip`> | Hish: Sounds like a quirks vs standards mode issue |
| 10:49 | <Philip`> | https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior mentions line height behaviour, so it's probably that |
| 10:49 | <Hish> | yep. but in this case, the standard behaviour doesn't make sense. also opera shows me that it can be displayed properly |
| 10:49 | <BenMillard> | Hish, maybe you could upload some test cases so others can see what's happening themselves? |
| 10:50 | <Hish> | do you have a pastebin here? |
| 10:50 | <Philip`> | If it's short, you can use the permalink feature on http://software.hixie.ch/utilities/js/live-dom-viewer/ |
| 10:51 | <takkaria> | I think either behaviour makes sense, really, there are pros and cons to either |
| 10:55 | <Philip`> | Can't you just do <!DOCTYPE html><p style="font-size:10pt"><span style="font-size:36pt">abc</span> some long text </p> ? |
| 10:56 | <Philip`> | (You probably don't want to use quirks mode (which is what you get with the HTML4 Transitional DTD, or with no doctype at all) because that makes browsers even more weird and buggy and uninteroperable) |
| 10:57 | <Hish> | http://pastebin.com/m5d342c7e |
| 10:59 | <BenMillard> | using <ol> for code samples is an anti-pattern...you can't copy and paste them :( |
| 10:59 | <Hish> | there's a download button |
| 11:00 | <Philip`> | There's a textarea you can copy from |
| 11:00 | <BenMillard> | Philip`, aha! it was below the fold |
| 11:00 | <Lachy> | WOW! I can't believe the stupidity in this video http://failblog.org/2008/09/08/conspiracy-fail/ |
| 11:01 | <Philip`> | Also you could use Opera, which doesn't insert annoying "#" lines if you copy-and-paste from the <ol> |
| 11:02 | <BenMillard> | Hish, does your test expect a specific browser width? |
| 11:03 | <Hish> | try 500px so that the small lines wrap over 2-3 lines |
| 11:05 | <BenMillard> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cmeta%20http-equiv%3D%22Content-Type%22%20content%3D%22text%2Fhtml%3B%20charset%3Dutf-8%22%3E%0A%3Ctitle%3EUntitled%20Document%3C%2Ftitle%3E%0A%3Cstyle%20type%3D%22text%2Fcss%22%3E%0Abody%20%7Bfont-size%3A6px%3B%7D%0A.style1%20%7B%0A%09font-size%3A36px%3B%0A%7D%0A.style2%20%7B%0A%20%20%20%20font-size%3A10px%3B%20%0A%7D%0 |
| 11:05 | <BenMillard> | %2Fhead%3E%0A%0A%3Cbody%3E%0A%3Cp%3E%3Cspan%20class%3D%22style2%22%3Ethis%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small |
| 11:05 | <BenMillard> | 20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20%3C%2Fspan%3E%3C%2Fp%3E%0A%3Chr%3E%0A%3Cp%3E%3Cspan%20class%3D%22style1%22%3Ebottomline%3A%20inline%20elements%20with%20a%20large%20font%20size%20must%20be%20closed%20before.%20Currently%20only% |
| 11:05 | <BenMillard> | s%20correctly.%20Now%20a%20small%20text%3C%2Fspan%3E%3Cspan%20class%3D%22style2%22%3Ethis%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20i |
| 11:05 | <BenMillard> | his%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20%3C%2Fspan%3E%3Cspan%20class%3D%22style1%22%3EOk.%20now%20back%20to%20large.%20%3C%2Fspan%3E%3C%2Fp%3E%0A%3Chr%3E%0A%3Cp%20class%3D%22style1%22%3E%3Cspan%20style%3D%22font-size%3 |
| 11:05 | <BenMillard> | is%20a%20test.%3C%2Fspan%3E%3Cspan%20class%3D%22style2%22%3Ethis%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this% |
| 11:05 | <takkaria> | fail! |
| 11:05 | <BenMillard> | 20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20%3C%2Fspan%3Enow%20back%20to%20large.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20a |
| 11:05 | <BenMillard> | 20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20%3C%2Fp%3E%0A%3Chr%3E%0A%3Cp%3E%3Cspan%20class%3D%22style1%22%3EThis%20part%20is%20only%20displayed%20correctly%20by%20opera.%20%3Cspan%20class%3D%22style2%22%3Ethis%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%2 |
| 11:05 | <BenMillard> | %20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20this%20is%20very%20small.%20%3C%2Fspan%3E |
| 11:05 | <BenMillard> | 20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20And%20also%20here%20a%20few%20lines.%20%3C%2Fspan%3E%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E |
| 11:05 | <BenMillard> | yikes, that was long |
| 11:07 | <gsnedders> | uh… |
| 11:07 | <gsnedders> | flooder! |
| 11:08 | gsnedders | agreess with takkaria |
| 11:09 | <Philip`> | I think you should pass it through hugeurl.com first |
| 11:09 | <gsnedders> | would that not shorten it? |
| 11:10 | <Philip`> | Uh, no, because it's HugeURL and its aim is not to shorten URLs |
| 11:13 | <BenMillard> | http://xrl.us/oxesv seems to work |
| 11:14 | <BenMillard> | "(0% of the original length)" lol |
| 11:17 | <Hish> | I don't see a difference to my doc |
| 11:17 | <Hish> | the line-heights are still too large |
| 11:18 | <BenMillard> | by "works" I mean "loads the correct page without flooding this channel" :) |
| 11:18 | <Hish> | ok... |
| 11:19 | <BenMillard> | the demo is more about CSS than HTML |
| 11:20 | <Hish> | it's more about different DTDs |
| 12:47 | <Hish> | just a quick thanks to all who helped me with this line-height thing. I solved it using a .class>* selector. |
| 13:55 | <BenMillard> | I see the phrase "spec lawyering" being used in documents and IRC logs but no clear explanation of what it means. |
| 13:56 | <BenMillard> | anyone care to enlighten me? :) |
| 14:05 | <hsivonen> | BenMillard: spec lawyering means reading a spec in very careful and pedantic way in order to extract precise meaning (as opposed to a more casual reading) |
| 14:05 | <BenMillard> | hsivonen, thanks! |
| 14:05 | <BenMillard> | does it imply that's a good or bad thing? |
| 14:07 | <hsivonen> | BenMillard: spec lawyering is good when implementing a spec, but it's not appropriate to expect e.g. Web authors to be spec lawyers |
| 14:11 | <BenMillard> | hsivonen, so if a web author does read a spec very carefully to extract the precise meaning of a particular feature, are they doing a good thing? |
| 14:12 | <hsivonen> | BenMillard: good thing, but we shouldn't write spec in such a way that they have to do that |
| 14:12 | <BenMillard> | I see |
| 15:27 | <jgraham> | https://listserv.heanet.ie/cgi-bin/wa?A2=ind9509&L=html-wg&D=0&P=32830 |
| 15:31 | <takkaria> | nice! |
| 15:35 | <takkaria> | DanC in his reply to that says, "But a more important question is: which will get us to reliable interoperability quicker: getting the document base to be SGML-conforming, or getting all the deployed software to agree on a specification derived from HTMLparse.c? |
| 15:39 | <jgraham> | It's interesting that his following assumption "We documents have a short half life"has tuned out to be fairly inaccurate |
| 15:51 | <Philip`> | jgraham: If you consider "We[b] documents" to be the collection of all documents on the web, and you reasonably assume that that collection is expanding exponentially, then it seems quite accurate to say that the half-life is short |
| 15:51 | <Philip`> | If the size of the web doubles every year, then the proportion of documents older than any given date will decay with a half life of one year |
| 15:56 | <takkaria> | also, back in '95, they only had a few years of data |
| 15:56 | <Dashiva> | And no geocities |
| 15:56 | <takkaria> | so everything was fairly recently edited, really |
| 15:57 | <Philip`> | "just stick around a while. Things will settle down." - and now, 13 years later... |
| 15:57 | <Philip`> | Did anyone back then expect they'd be sticking around for so long a while? :-) |
| 16:00 | <takkaria> | that a strategy has been pursued for thirteen years and has failed seems to count as good reasoning for taking a different approach |
| 16:08 | <Philip`> | You're willing to wave the white flag of surrender and throw out all that work when we may be on the cusp of success? |
| 16:09 | <jgraham> | Philip`: It seems unfair to look at the original documents in fractional terms. A more interesting question would be given a fixed sample of documents how many of them are still useful/avaliable n years later |
| 16:10 | <jgraham> | s/terms/terms relative to the current web/ |
| 16:10 | <takkaria> | Philip`: sounds suspiciously like the arguments against drug law reform |
| 16:12 | jgraham | really doesn't understand why people get hung up about "clean" markup anyway |
| 16:13 | <jgraham> | There are obvious advantages to the original author |
| 16:14 | <Philip`> | Maybe because people wish the world was nice and clean and sensible and understandable, not just a giant collection of hacks, and so they want to promote moving in that direction |
| 16:16 | <jgraham> | But I wonder why they wish that. Is it just a built in sense of aesthetics or is there a practical benefit that can actually be realied |
| 16:16 | <jgraham> | realised |
| 16:16 | <jgraham> | I guess there might be some correlation between having conformant markup and people being able to use tools like greasemonkey although it's not obvious that that is always true |
| 16:17 | <Philip`> | Why do you say "just"? Most of human art and mathematics is about striving for aesthetics, so it seems a fairly important goal :-) |
| 16:18 | jgraham | is going to ask for arts council funding next time he writes a html document |
| 16:20 | <Philip`> | It's not about the aesthetics of a single HTML document, it's about the aesthetics of the entire system and associated culture |
| 16:36 | <jgraham> | Philip`: In that case we alreasy lost and the esthetics argument should die :) |
| 16:36 | <jgraham> | aesthetics |
| 16:45 | <takkaria> | I dunno, you could probably do some funky ASCII art that was also valid HTML |
| 17:56 | <Philip`> | jgraham: Just because perfection is unattainable, that doesn't mean you should stop striving for it :-) |
| 18:49 | <Hixie> | a lot of geeks, to some extent or another, suffer from a series of mental conditions that have in common a fundamental desire for tidyness |
| 18:49 | <Hixie> | it's not necessarily a rational thing, though geeks, given their usually high level of intelligence, will often find rationalisations for it |
| 18:50 | <Hixie> | being of that mindset myself, i would quite like markup to be more widely conforming myself :-) |
| 18:50 | <Dashiva> | I have that obsession with code and other digital things, but my apartment is a right mess |
| 18:50 | <Hixie> | yeah it varies from person to person |
| 18:51 | <Hixie> | i'm similar |
| 18:51 | <Hixie> | i know people who are the opposite |
| 20:46 | <othermaciej> | I think the root geek desire is not necessarily for tidiness as such but for consistency |
| 20:46 | <othermaciej> | and for fitting into a system |
| 20:46 | <othermaciej> | at least as to technical things |
| 21:39 | <hsivonen> | I wonder what kind of client-side software Roy Fielding would ship |
| 21:41 | <takkaria> | bad client-side software? :) |
| 21:42 | <Dashiva> | What's the context now? |
| 21:43 | <jmb> | that rather depends if the html his software is dealing with has come from the web or not |
| 21:45 | <hsivonen> | Dashiva: public-html |
| 21:46 | <takkaria> | it surprises me a bit that he doesn't think most web authors don't author for browsers |