| 00:02 | <Hixie> | how on earth an i going to spec this: <!DOCTYPE html>...<img name=a><img name=a><script>x = document.a; y= document.a; w(x === y);</script> |
| 00:02 | <Hixie> | in safari and firefox, x !== y |
| 00:02 | <Hixie> | but in IE x === y |
| 00:02 | <Hixie> | wonder what opera does |
| 00:03 | <Hixie> | true in opera too |
| 00:03 | <Hixie> | well bummer |
| 00:07 | <Hixie> | hsivonen: "http://www.whatwg.org/specs/web-apps/current-work/source-whatwg":-11.40--11.46: error: Required attributes missing on element "label". |
| 00:07 | <Hixie> | hsivonen: the <label> contains an <input> |
| 00:07 | <Hixie> | hsivonen: so that seems like a bug in the validator |
| 00:07 | <annevk> | Hixie, why would it be false? |
| 00:08 | annevk | also notes that in Firefox it's a NodeList while in Opera an HTMLCollection |
| 00:08 | <Hixie> | yeah Firefox was disqualified a while back |
| 00:08 | <Hixie> | safari just returns a new HTMLCollection each time |
| 00:08 | <Hixie> | but IE and Opera memoise the getter |
| 00:08 | <Hixie> | which requires an annoying sentence to spec |
| 00:08 | <annevk> | it's weird, especially when you compare with e.g. document.images |
| 00:09 | <Hixie> | hm? |
| 00:09 | <annevk> | if you replace the a with images Firefox does return true |
| 00:09 | <Hixie> | well sure |
| 00:09 | <Hixie> | why would it not |
| 00:09 | <annevk> | why would it not for a? |
| 00:09 | <Hixie> | there's only one .images collection |
| 00:10 | <Hixie> | so you can just hardcode an instance internally |
| 00:10 | <annevk> | there's also only one a collection per page... |
| 00:10 | <Hixie> | for .a you have to do all kinds of caching work |
| 00:10 | <Hixie> | no |
| 00:10 | <Hixie> | there might not be an 'a' collection at all |
| 00:10 | <Hixie> | in fact most names don't have a corresponding colleciton |
| 00:10 | <Hixie> | collection |
| 00:12 | <annevk> | I guess that's fair enough, though it seems weird for the two to be different to me |
| 00:12 | <annevk> | anyway, how does "The images attribute must return an HTMLCollection rooted at the Document node, whose filter matches only img elements." ensure that the same object is returned each time? |
| 00:12 | <Hixie> | the spec currently doesn't ensure it |
| 00:12 | <Hixie> | for .images |
| 00:12 | <Hixie> | oh wait |
| 00:13 | <Hixie> | actually it does |
| 00:13 | <Hixie> | An attribute that returns a collection must return the same object every time it is retrieved. |
| 00:13 | <Hixie> | i guess that means i don't have to define it explicitly for the getter either |
| 00:44 | <rubys> | http://intertwingly.net/blog/2009/01/12/IE8-Beta-7000-Bug |
| 00:44 | rubys | wonders whether or not the IE8 team is aware of his blog, or if they just don't care |
| 00:46 | <annevk> | they have a bug database |
| 00:46 | <Hixie> | IE bugs frighten me |
| 00:47 | <Hixie> | i can't even begin to imagine what their code must look like at this point |
| 00:47 | <rubys> | annevk: how do I access their database? |
| 00:50 | <annevk> | https://connect.microsoft.com/IE/Feedback is it I think |
| 00:50 | <rubys> | oh, and Hixie: I got final approval to travel to MountainView to meet with the ECMAScript folks on the 27th-29th; we could meet on the afternoon/evening of the 27th? |
| 00:50 | <Hixie> | january? |
| 00:51 | <rubys> | yes |
| 00:51 | <Hixie> | hold on |
| 00:51 | <Hixie> | sure |
| 00:51 | <Hixie> | what time? |
| 00:52 | <rubys> | when I make flight arrangements and I'll back to you, but if you can "pencil me in" for now, I'd appreciate it. |
| 00:52 | <Hixie> | sure |
| 00:52 | <annevk> | r2645 is weird |
| 00:52 | <Hixie> | rubys: blocked out 3pm to 8pm on the 27th |
| 00:52 | <rubys> | annevk: it requires me to sign in. Once I do so, I get a The content that you requested cannot be found or you do not have permission to view it. |
| 00:52 | <annevk> | I've read the topic, but still |
| 00:53 | <annevk> | rubys, :/ |
| 00:53 | <annevk> | rubys, maybe blog that too, they might find it one day or you could tell the other chair ;) |
| 00:54 | <Hixie> | annevk: if you think that's fun you should see the next checkin (same thing, but for Window...) |
| 00:54 | <Hixie> | (might not be the very next one) |
| 00:54 | annevk | will check tomorrow |
| 00:54 | <annevk> | nn |
| 00:54 | <Hixie> | nn |
| 00:56 | <Philip`> | rubys: The IE8 bug database is invitation-only |
| 00:56 | <Philip`> | rubys: I think I have an invitation code somewhere which you could have |
| 00:57 | <rubys> | *sigh* |
| 00:57 | <rubys> | brb |
| 00:57 | <Hixie> | i have access but i can't say it's ever helped me (or helped me help them) |
| 00:58 | <Hixie> | it makes bugzilla look positively easy to use |
| 00:58 | Philip` | has reported some bugs which got fixed, though he doesn't know if they got fixed because of his bug report |
| 00:58 | <Hixie> | as far as i can tell the engineers don't interact with that bug database |
| 00:59 | <Hixie> | which makes it pretty pointless to me |
| 01:27 | <BenMillard> | Philip`, JZWSA sounds like the QA tools I've seen come and go over the past 5+ years. Nothing new and I'm amazed at it costing $50 when it's not even a standalone application. |
| 01:27 | <BenMillard> | krijnh, how about linkifying e-mail addresses and mailto: links? http://krijnhoetmer.nl/irc-logs/whatwg/20090112#l-513 |
| 01:38 | <BenMillard> | krijnh, could linkification infer http:// when it's absent? http://krijnhoetmer.nl/irc-logs/whatwg/20090113#l-104 |
| 01:46 | <BenMillard> | heycam, there's no bot, but you can go to the web interface and click the # character at the start of the line manually to get this: http://krijnhoetmer.nl/irc-logs/whatwg/20090113#l-25 |
| 02:08 | <Hixie> | heycam: yt still? |
| 02:09 | <Hixie> | hm wait |
| 02:09 | <Hixie> | nm |
| 02:20 | hallvors | tried googling JZWSA and was asked if I meant JEWS |
| 02:20 | <Dashiva> | Heh. I tried using Japanese characters for labels in a google chartserv request, and it turned everything in the chart into a different font :) |
| 02:28 | <BenMillard> | hallvors, JZWSA is referring to this: http://www.zeldman.com/2009/01/12/jeffrey-zeldmans-web-standards-advisor/ |
| 02:35 | <hallvors> | BenMillard: thanks :) |
| 07:04 | <Hixie> | heycam: if you're still here: how do i say that my anonymous [NamedGetter] overrides the other attributes on the interface? |
| 07:05 | <Hixie> | oh wait, i may have decided i didn't need that |
| 07:09 | <Hixie> | no, i do need it after all |
| 07:09 | <Hixie> | heycam: i need to be able to say that document.body is overriden by the [NamedGetter] if there is a conflict |
| 07:16 | <heycam> | Hixie, no way to do that currently. all interface members take precedence of named properties. |
| 07:16 | <Hixie> | i have a feature request :-) |
| 07:16 | <heycam> | :) |
| 07:17 | heycam | notes it |
| 07:17 | <Hixie> | thanks |
| 07:17 | <Hixie> | wanna guess a syntax so i can use it now, or should i leave an XXX? |
| 07:18 | <Hixie> | (either is fine by me) |
| 07:19 | <heycam> | if you can think of a good name to put on the attribute |
| 07:20 | <heycam> | [OverridesNamedProperty]? a bit long maybe. |
| 07:20 | <Hixie> | [NamedGetter=OverrideBuiltins] |
| 07:20 | <Hixie> | maybe? |
| 07:20 | <heycam> | but you don't want it to apply to all |
| 07:20 | <heycam> | just to particular members, no? |
| 07:21 | <Hixie> | as far as i can tell, document.foo returns applicable elements with name=foo rather than returning the interface-defined document.foo for all values of foo |
| 07:21 | <Hixie> | but i could be wrong |
| 07:21 | <heycam> | oh, so is that the other way around from what you said first? |
| 07:22 | <Hixie> | maybe, i've been very confused today |
| 07:22 | <heycam> | :) |
| 07:22 | <Hixie> | let me get you an actual testcase |
| 07:22 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Ciframe%20name%3Dbody%3E%3C%2Fiframe%3E%3Cscript%3Ew(document.body)%3C%2Fscript%3E |
| 07:22 | <Hixie> | IE says "[object Window]" in the log |
| 07:23 | <Hixie> | meaning it returned the iframe's contentWindow |
| 07:23 | <Hixie> | rather than the HTMLBodyElement |
| 07:23 | <Hixie> | as one would expect if the channel's topic didn't apply |
| 07:23 | <Hixie> | as far as i can tell that is true for all values of 'body' |
| 07:23 | <Hixie> | e.g. document.links |
| 07:24 | <Hixie> | does that make sense? |
| 07:24 | <heycam> | so for objects that implement HTMLDocument, a named property always overrides something from prototypes? |
| 07:24 | <Hixie> | looks that way |
| 07:25 | <Hixie> | i have not yet found a counter-example at least |
| 07:25 | <heycam> | ok |
| 07:25 | <heycam> | just do [NamedGetter=OverrideBuiltins] for now and i'll think about naming later |
| 07:26 | <Hixie> | k cool thanks |
| 07:47 | <zcorpan> | Hixie: hmm, i was going to say that you missed this case <iframe name=x></iframe><embed name=x><script>w(document.x[0])</script> but it seems the spec matches ie, webkit and opera |
| 07:47 | <Hixie> | returns the <iframe> element, right? |
| 07:47 | <Hixie> | not a Window? |
| 07:47 | <zcorpan> | right |
| 07:47 | <Hixie> | good :-) |
| 07:48 | <Hixie> | man the stuff i specced today puts the topic to work |
| 07:48 | <zcorpan> | indeed :) |
| 07:54 | <MikeSmith> | zcorpan: are you in Linköping? |
| 07:57 | <zcorpan> | MikeSmith: yes |
| 07:58 | <MikeSmith> | If you could forward the following to Jens or somebody, I'd appreciate it |
| 07:58 | <MikeSmith> | http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200901/msg00218.html |
| 07:59 | <MikeSmith> | guy trying to debug an XSLT problem in Opera |
| 08:01 | <MikeSmith> | or maybe to whoever is responsible for QA for XSLT |
| 08:01 | <MikeSmith> | used to be Kaz |
| 08:06 | <Hixie> | oooh, WebIDL has [Callable=...] |
| 08:06 | <Hixie> | sweet |
| 08:06 | <Hixie> | weinig: your input on https://bugs.webkit.org/show_bug.cgi?id=23284 would be much appreciated |
| 08:07 | <weinig> | Hixie: sure |
| 08:13 | <zcorpan> | MikeSmith: done |
| 08:15 | <MikeSmith> | zcorpan: thanks |
| 08:25 | <weinig> | Hixie: I think it was just a mistake |
| 08:25 | <Hixie> | has a version shipped with that bug? |
| 08:25 | <weinig> | Hixie: I don't really care which way we go on property name precedence in the window, as long as we can all do the same thing |
| 08:25 | <weinig> | Hixie: I don't think so |
| 08:26 | <Hixie> | ok well then we should probably do what the comment says |
| 08:26 | <Hixie> | though you should fix the spelling of 'toolbar' when you fix it |
| 08:26 | weinig | nods |
| 08:26 | <weinig> | heh |
| 08:26 | Hixie | fixes the bug |
| 08:26 | <Hixie> | er |
| 08:26 | <Hixie> | the spec |
| 08:26 | <Hixie> | freudian slip there |
| 08:57 | <annevk> | heh, http://twitter.com/themadness/statuses/1115257406 |
| 08:59 | <MikeSmith> | annevk: I like his previous tweet better: |
| 08:59 | <MikeSmith> | http://twitter.com/theMadness/status/1115207606 |
| 09:00 | <annevk> | heh, just found it through a search |
| 09:08 | Hixie | replies |
| 09:08 | <Hixie> | heycam: if you're still there... Apparently I need a new kind of [Replaceable]. |
| 09:08 | <Hixie> | heycam: for event handler DOM attributes |
| 09:09 | <Hixie> | heycam: they have to be able to take a string, at which point they do nothing |
| 09:09 | <Hixie> | heycam: but if later they are set back to a function, they work again |
| 09:09 | <Hixie> | heycam: also, if set to anything other than a string or a function, they throw an exception |
| 09:14 | <Hixie> | sicking: do you know what the current state of things is w.r.t. [Null] in WebIDL? |
| 09:14 | <Hixie> | sicking: specifically, i seem to recall you raised an objection to the current text |
| 09:14 | <annevk> | that discussion didn't move |
| 09:22 | <Hixie> | bummer |
| 09:22 | <hsivonen> | Hixie: fixed. |
| 09:22 | <Hixie> | heycam: i found an object for which i need enumeration (i.e. for which I don't want [DontEnum]) - Storage |
| 09:22 | <Hixie> | hsivonen: thanks |
| 09:23 | <Hixie> | heycam: same object also supports indexed properties that I _don't_ want enumerated, fwiw |
| 09:24 | <annevk> | Hixie, what's the use cases for data: URL form submission? |
| 09:24 | <annevk> | Hixie, mostly debugging? |
| 09:25 | <Hixie> | yeah |
| 09:25 | <annevk> | ta |
| 09:38 | <hsivonen> | http://www.joelonsoftware.com/items/2009/01/12.html |
| 09:38 | <MikeSmith> | hsivonen: great to hear that patches are now deployed at validator.nu |
| 09:39 | <hsivonen> | considering how well "power of Java" and "power of RDF" are doing, we should probably avoid advertising "power of HTML5" |
| 09:39 | <Hixie> | lord, i hope nobody says anything about the "power" of HTML |
| 09:40 | <hsivonen> | MikeSmith: now I should probably locate emails about Validator.nu bugs over the last three months or so and reply that the bugs have been fixed... |
| 09:40 | <MikeSmith> | HTML can kick Chuck Norris's ass |
| 09:40 | <MikeSmith> | hsivonen: yup |
| 09:40 | <Hixie> | HTML probably couldn't kick _my_ ass |
| 09:41 | <Hixie> | and i'm no ass-kicker |
| 09:42 | <Hixie> | our open Web standards platform is like the dictionary definition of "worse is better" or "good enough is good enough" or whatever cliche you want to use that asserts that the most successful technology is usually a disaster :-) |
| 09:43 | <Hixie> | sadly what makes something useful and widely used isn't the same as what makes it aethetically pleasing |
| 09:45 | <MikeSmith> | HTML has the powerful like the Blob -- if you try to punch it, you just stumble and get sucked in and completely covered with goo |
| 09:45 | <MikeSmith> | hmm, hsivonen - having problems building local v.nu from current sources |
| 09:46 | <MikeSmith> | ./syntax/relaxng/datatype/java/src/org/whattf/datatype/Html5DatatypeLibrary.java:146: cannot find symbol |
| 09:46 | <MikeSmith> | symbol : variable Color |
| 09:46 | <MikeSmith> | etc. |
| 09:46 | <MikeSmith> | plus: ./syntax/non-schema/java/src/org/whattf/checker/TextContentChecker.java:85: package DateOrTimeContent does not exist |
| 09:47 | <MikeSmith> | can send you the build log if you want |
| 09:52 | <annevk> | html5.org so far in January: 31847 200, 165596 403; will that bot ever learn? |
| 10:00 | <hsivonen> | MikeSmith: oops. fixed now. Thanks. |
| 10:13 | annevk | sighs |
| 10:13 | <Hixie> | hm? |
| 10:13 | <annevk> | meh, see whatwg⊙wo |
| 10:13 | annevk | hopes it's clear now |
| 10:14 | <annevk> | Hixie, since you're still awake, any ETA on a new definition of "scripting context"? |
| 10:15 | <Hixie> | is that test not wrong? |
| 10:15 | <annevk> | no |
| 10:15 | <Hixie> | two things match, but only one is in the expected output? |
| 10:15 | <Hixie> | also the title is very misleading :-) |
| 10:15 | <Hixie> | no ETA on scripting context issue |
| 10:15 | <annevk> | oh wow, fail |
| 10:17 | annevk | updates test |
| 10:17 | annevk | somehow missed the second element |
| 10:20 | <MikeSmith> | hsivonen: thanks, synced up and running now |
| 10:21 | <MikeSmith> | but fwiw, some tests are failing with: |
| 10:21 | <MikeSmith> | Element “html” from namespace “http://www.w3.org/1999/xhtml” not allowed in this context. Suppressing further errors from this subtree. |
| 10:21 | <MikeSmith> | File: file:/opt/checker/syntax/relaxng/tests/html5full-html/valid/002.xhtml |
| 10:21 | <MikeSmith> | Line: 1 Col: 43 |
| 10:21 | <MikeSmith> | etc. |
| 10:29 | <Hixie> | heycam: i find the text in "3.8.5. [IndexCreator], [IndexDeleter], [IndexGetter] and [IndexSetter]" and "4.4.2. Indexed and named properties" to be confusingly different |
| 10:29 | <Hixie> | heycam: they both have what look like normative conformance criteria and language defining what is should say, but it is defined in different terms |
| 10:30 | <Hixie> | heycam: so i don't know if what i'm doing is right |
| 10:30 | <Hixie> | heycam: i'd prefer to see the JS one defined in terms of the generic one |
| 10:59 | <Hixie> | WTF |
| 10:59 | <Hixie> | are you KIDDING ME? |
| 10:59 | <Hixie> | #%&@#(^&@# |
| 11:00 | <Hixie> | <!DOCTYPE html><form><input></form><script>w(typeof document.forms[0].item)</script> |
| 11:00 | <Hixie> | -> string! |
| 11:00 | <Hixie> | specifically, the string "[HTMLFormElement]" |
| 11:00 | <Hixie> | but it's callable! |
| 11:00 | <Hixie> | <!DOCTYPE html><form><input></form><script>w(document.forms[0].item())</script> |
| 11:01 | <Hixie> | -> HTMLInputElement |
| 11:01 | <Hixie> | the object, that is |
| 11:01 | <annevk> | welcome to logicfreezone |
| 11:02 | <Hixie> | i'm guessing this is an IE8 bug |
| 11:02 | <Hixie> | because even for IE, this is crazy land |
| 11:02 | <Philip`> | IE6 says typeof is 'string' |
| 11:03 | <Philip`> | (stringifying to '[object]') |
| 11:03 | <Hixie> | so what exactly is .item then? |
| 11:03 | <Hixie> | i know that form.elements === form |
| 11:03 | <Hixie> | (in IE) |
| 11:03 | <Hixie> | but what is form.item? |
| 11:03 | <annevk> | nice, just like window.frames |
| 11:03 | <Hixie> | since when are strings callable? |
| 11:04 | <Philip`> | It's not a string, it's just an object whose type is string :-) |
| 11:04 | <Hixie> | indeed, it's definitely not a string, you can't index into it for example |
| 11:04 | <Hixie> | <!DOCTYPE html><form><input></form><script>w(document.forms[0].item[0])</script> -> undefined |
| 11:04 | <annevk> | btw, <form><input> without an "x" or something in front of it gives you a fucked up DOM |
| 11:05 | <Hixie> | heh so it does |
| 11:05 | <Hixie> | i don't think this is affecting these results though |
| 11:05 | <zcorpan> | <form><input type=hidden> makes the input be in head |
| 11:06 | <annevk> | hmm, document.forms[0].item == document.forms[0] but not === |
| 11:06 | <Hixie> | annevk: yeah, you're just stringifying both if you do that |
| 11:07 | <annevk> | I see |
| 11:09 | <annevk> | funny, item[0] is undefined ,as you say, but item(0) is object |
| 11:11 | <annevk> | for(x in document.forms[0].item) doesn't reveal anything |
| 11:12 | <Philip`> | Why is that funny? With function f(){return null}, f[0] is undefined and f(0) is object, so it's not particularly unusual behaviour |
| 11:12 | <annevk> | Isn't it just the IE way to denote a function? |
| 11:12 | <Hixie> | <!DOCTYPE html>...<form><select><option>x</select></form><script>w(document.forms[0][0]('0'))</script> -> [object HTMLSelectElement] |
| 11:12 | <Hixie> | ... |
| 11:12 | <Hixie> | what? |
| 11:13 | <Hixie> | in fact, it returns that for any value of the argument |
| 11:13 | <Hixie> | BUT |
| 11:13 | <Hixie> | <!DOCTYPE html>...<form><select><option>x</select></form><script>w(document.forms[0][0]())</script> -> undefined |
| 11:13 | <Philip`> | annevk: Not sure what you mean |
| 11:15 | <annevk> | I thought that maybe the weird behavior of item was normal |
| 11:15 | <annevk> | doesn't seem like it |
| 11:15 | <annevk> | funny when you compare .item with .namedItem |
| 11:17 | <Hixie> | i am so confused right now |
| 11:20 | jgraham | is worried that trying to understand IE may leave Hixie in no state to edit the spec. Or do anything really. Except go with the nice men in their white coats |
| 11:21 | annevk | lolz |
| 11:22 | <Hixie> | aggnnnnewwwg |
| 11:22 | <Hixie> | <!DOCTYPE html>...<form><input name=a></form><script>var f = document.forms[0]; w(f('a')); w(document.forms[0]('a'))</script> |
| 11:22 | <Hixie> | -> [object HTMLInputElement] [object HTMLFormElement] |
| 11:22 | <Hixie> | !!!!!!!!!!!!!!!!!!!!1111111oneoneoneohenneeohenneegah |
| 11:23 | annevk | gets worried too now |
| 11:24 | <jgraham> | I think it safe to assume that this bit of IE was implemented by repeatedly getting a cat to walk over the keyboard until something compiled |
| 11:26 | <Philip`> | I don't think cats could design something so perverse |
| 11:26 | <Hixie> | i wonder if heycam would fall for it if i told him i needed something to spec the last thing i pasted here |
| 11:27 | <annevk> | how would that even work? |
| 11:27 | <Hixie> | just like in IE! |
| 11:27 | <Dashiva> | Magic |
| 11:27 | <annevk> | how does it even work, I should say :) |
| 11:30 | <Hixie> | wow |
| 11:30 | <Hixie> | IE doesn't index on <option name=""> |
| 11:30 | <Hixie> | only <option id=""> |
| 11:30 | <Lachy> | Hixie, shouldn't that be w(f]'a']); (using square brackets, not parentheses)? |
| 11:30 | <Lachy> | oops, I meant w(f([a']); |
| 11:30 | <Lachy> | aargh. you know what I mean. |
| 11:30 | <Hixie> | i'm testing (and speccing) the Callable=namedItem behavior |
| 11:31 | <Hixie> | the NameGetter=namedItem behavior is a separate kettle of rotten fish entirely |
| 11:31 | <Lachy> | oh. I didn't know that you could call it as a function. Does it work in any browser except IE? |
| 11:31 | annevk | looks forward to this week in HTML5, should be easy to write: "There be dragons." |
| 11:32 | <Hixie> | Lachy: at least one case works in safari |
| 11:32 | <Hixie> | oh jesus |
| 11:32 | <Hixie> | select.item('a') actually returns something |
| 11:32 | <Hixie> | works just like .namedItem('a') |
| 11:32 | <Hixie> | i hope nobody minds if this part of the spec isn't 100% IE compatible |
| 11:33 | <Hixie> | but I don't think I can actually spec what IE does without violating some fundamental laws of physics |
| 11:33 | <annevk> | you're saying IE beats physics? |
| 11:34 | <zcorpan> | maybe our understanding of physics is flawed |
| 11:34 | <zcorpan> | and the real world is more like ie |
| 11:36 | jgraham | hopes Bell's theroem doesn't apply to IE |
| 11:37 | <Hixie> | that would be bad |
| 11:38 | <Philip`> | It's all just spooky action at a distance |
| 11:39 | <Lachy> | Hixie, I couldn't get that above script to work in either Firefox, Opera or Safari |
| 11:40 | <Hixie> | i'm actually more worried that the theory expounded upon at the start of the The Restaurant at the End of the Universe is the one that applies here |
| 11:40 | <Hixie> | Lachy: i don't think any of them do this for option and select, no |
| 11:41 | <Philip`> | Did the latest version of IE8's developer tools remove the DOM-properties view? I can't find it anywhere |
| 11:42 | <Lachy> | Hixie, I meant this one: <form><input name=a></form><script>var f = document.forms[0]; w(f('a')); w(document.forms[0]('a'))</script> |
| 11:42 | <Lachy> | it only works in IE |
| 11:42 | <Hixie> | yeah i don't think callable forms is supported by the others either |
| 11:43 | <zcorpan> | maybe f.elements('a')? |
| 11:44 | <annevk> | that should be identical to f('a') |
| 11:44 | <annevk> | in IE anyway |
| 11:45 | <annevk> | we could copy that in HTML5 I think |
| 11:45 | <Hixie> | it's already in html5 |
| 11:45 | <Hixie> | oh actually that one isn't |
| 11:46 | <annevk> | then we could drop HTMLFormControlsCollection |
| 11:46 | <annevk> | I suppose |
| 11:46 | <Hixie> | i don't intend to |
| 11:46 | <Hixie> | but we could |
| 11:46 | <Hixie> | oh actually it is already in html5, sorry |
| 11:46 | <Hixie> | i was confusing it with something else |
| 11:47 | <annevk> | hmm, not in my copy |
| 11:47 | <annevk> | " readonly attribute HTMLFormControlsCollection elements;" |
| 11:49 | <Hixie> | i thought you were saying we should make elements callable |
| 11:51 | <annevk> | no, I meant removing that interface in favor of just having <form> |
| 11:52 | <annevk> | might not be needed though, just an idea |
| 11:52 | <Hixie> | yeah, we could. i don't intend to. |
| 11:52 | <annevk> | it would be nice if [Callable=namedItem] and all were inside the interface def |
| 11:53 | <annevk> | if you link to e.g. HTMLFormElement you won't see it |
| 11:53 | <Hixie> | dunno how to change that |
| 11:53 | <annevk> | alternatively we could do one interface per <pre> and have the linking work differently |
| 11:54 | <Hixie> | that's either heycam's problem or gsnedders'. :-) |
| 11:54 | <annevk> | well, heycam could just move them inside... :) |
| 11:54 | <Hixie> | not without breaking compat with OMG IDL |
| 11:54 | <annevk> | well, one interface per <pre> is also years |
| 11:54 | <annevk> | I see |
| 11:58 | <Hixie> | heycam: it's unfortunate that for the enumeration stuff i have to first list how to get the list of names, then list how to get the mapping of name to value |
| 11:58 | <Hixie> | heycam: since those two operations are so similar |
| 12:06 | <Hixie> | ok i'm taking a break |
| 12:06 | <Hixie> | before i lost my sanity |
| 12:06 | <Hixie> | forms are crazy |
| 12:06 | <Hixie> | dom level 0 is crazy |
| 12:06 | <Hixie> | IE is crazy |
| 12:06 | <Hixie> | all three together = crazitasticness |
| 12:08 | <Philip`> | Does anyone still have IE8b2? |
| 12:09 | <Philip`> | If so: Does <!DOCTYPE html><svg xmlns=x> give an element called 'svg' inside HEAD, or an element called 'SVG' before HTML? |
| 12:10 | <Philip`> | (It gives the former in IE8RC1, and parses elements inside there with its normal XMLish rules rather than its normal HTML ones) |
| 12:11 | <Philip`> | (and it does that for seemingly any unrecognised element, with an xmlns attribute that contains at least one character) |
| 12:12 | <Hixie> | in the dom viewer, "<!DOCTYPE html><svg xmlns=x>s" says: |
| 12:12 | <Hixie> | http://junkyard.damowmow.com/350 |
| 12:13 | <Hixie> | ie8b2 |
| 12:13 | <Hixie> | Philip`: ^ |
| 12:13 | <Philip`> | Thanks |
| 12:13 | <Philip`> | Look like it's changed in RC1, then |
| 12:13 | <Hixie> | what do later beta do? |
| 12:13 | <Philip`> | *Looks |
| 12:14 | <Philip`> | Hixie: They give: |
| 12:14 | <Philip`> | HTML |
| 12:14 | <Philip`> | HEAD |
| 12:14 | <Philip`> | TITLE |
| 12:14 | <Philip`> | svg xmlns="x" |
| 12:15 | <Philip`> | and you can write <svg xmlns=x><foo><bar/><baz/></foo></svg> and it'll parse into the same kind of tree as if it were XML |
| 12:15 | <Hixie> | and without the xmlns? |
| 12:16 | <Philip`> | Without that, it does the same as IE8b2 (which is the same as IE7 and IE6) |
| 12:17 | <Hixie> | so basically they just added xmlns="" as a way to do what used to be only possible with a prefix? |
| 12:17 | <Philip`> | Yes |
| 12:17 | <Hixie> | i wonder how many pages that breaks |
| 12:18 | <Hixie> | given how common xmlns="" attributes are |
| 12:18 | <Philip`> | It's only on unrecognised elements, so it won't affect most |
| 12:19 | <Hixie> | i love how they still support style="", onclick="", etc, on these elements |
| 12:20 | <Hixie> | what happens with things like: <html>...<foo xmlns="">...<input type=submit> ? |
| 12:24 | <Philip`> | You get a submit button |
| 12:26 | <Hixie> | so e.g. <svg xmlns=""> ... <font> ... <script> ... </svg> wouldn't have svg <font> amd <script> elements? |
| 12:27 | <Philip`> | <svg xmlns=x><font color=red>Hello</font></svg> is rendered as red text |
| 12:27 | <Philip`> | (with the FONT element being a child of the svg element) |
| 12:28 | <Hixie> | good times |
| 12:28 | <Hixie> | ok |
| 12:28 | <Hixie> | bed time |
| 12:28 | <Hixie> | nn |
| 13:28 | <MikeSmith> | hsivonen: I notice you changed the content model for colgroup |
| 13:29 | <MikeSmith> | how are you having validator.nu enforce the constraint that a colgroup with a col child can't have a span attribute? |
| 13:34 | <zcorpan> | colgroup = (col* | colgroup.attrs.span?) & colgroup.attrs |
| 13:34 | <hsivonen> | MikeSmith: it's quite possible that I'm not |
| 13:34 | <MikeSmith> | hsivonen: it seems you changed the content model in r371 |
| 13:34 | <MikeSmith> | in table.rnc |
| 13:35 | <hsivonen> | I added span, but I forgot about the child restriction in that case |
| 13:36 | <MikeSmith> | hsivonen: I think it worked as expected the way you had it before |
| 13:36 | <MikeSmith> | what zcorpan cited above |
| 13:36 | <hsivonen> | oh. |
| 13:49 | <hsivonen> | checked in but my deployment script isn't working reliably |
| 13:50 | <MikeSmith> | OK |
| 14:17 | <hsivonen> | MikeSmith: now deployed. |
| 14:17 | <MikeSmith> | hsivonen: thanks |
| 15:51 | <annevk> | namespace without documentation: http://wordpress.org/export/1.0/ :/ |
| 15:52 | <gsnedders> | annevk: WXR isn't even XML anyway |
| 15:52 | <gsnedders> | annevk: WP's WXR parser totally ignores namespaces, too. |
| 15:52 | <annevk> | that's all cool, I just need to be able to write it so WordPress can consume all my content |
| 15:52 | <gsnedders> | annevk: It basically uses regexes to parse it |
| 15:52 | <gsnedders> | annevk: OK, make sure you use CDATA blocks where WP does. |
| 15:52 | <hsivonen> | WP seems to have given up on its ideals since it overtook MT as the most popular blogging platform |
| 15:53 | <gsnedders> | hsivonen: I'd argue before that, but hey |
| 15:53 | <hsivonen> | annevk: are you migrating from your own system to WP? |
| 15:53 | <annevk> | I was thinking about it, yes |
| 15:53 | <zcorpan> | why? |
| 15:53 | <Philip`> | gsnedders: Would you argue that giving up on its ideals was a necessary factor in its becoming the most popular blogging platform? |
| 15:53 | <annevk> | to more easily get OpenID support and all |
| 15:53 | <gsnedders> | annevk: Take a look at Habari. |
| 15:53 | <gsnedders> | Philip`: No |
| 15:53 | <Lachy> | woah. I wouldn't. Personally, I want to migrate away from WP to my own system. I just don't have time to write it |
| 15:53 | <Philip`> | gsnedders: Oh, okay then |
| 15:54 | gsnedders | points towards #habari |
| 15:54 | <gsnedders> | With wonders such as: output as HTML! |
| 15:54 | <gsnedders> | Using a serializer to create XML! |
| 15:54 | <gsnedders> | All these bizarre things. |
| 15:55 | <annevk> | gsnedders, does Habari describe an import format I can generate? |
| 15:55 | <gsnedders> | annevk: Admittedly, no |
| 15:55 | annevk | doesn't find it in the documentation |
| 15:56 | <zcorpan> | gsnedders: does it use an html5 parser and serializer? |
| 15:56 | <gsnedders> | zcorpan: No |
| 15:56 | <gsnedders> | s9y,wordpress,MT,blogger importers. |
| 15:57 | <Lachy> | Habari looks nice. I might have to give it a try |
| 15:58 | <annevk> | maybe I should just generate a bunch of static pages of all content I have so far and start over... |
| 15:58 | <gsnedders> | annevk: How's it stored currently? |
| 15:59 | <annevk> | table for posts, table for comments, table for tags, some linking between them, iirc |
| 15:59 | <gsnedders> | How much is stored as XML? Comments are, aren't they? Posts too I assume? |
| 16:00 | <annevk> | "XML fragments" |
| 16:00 | <annevk> | they actually don't have a root in the database |
| 16:00 | <annevk> | so I can use string concat in the end :) |
| 16:00 | <gsnedders> | I think that'll probably be the hardest part of moving to any other system: any other system assumes HTML or HTML-compat XHTML :) |
| 16:02 | <annevk> | it stores Atom IDs as well, has two different summary fields, etc. |
| 16:02 | <annevk> | two different title fields too |
| 16:02 | <annevk> | one text/plain and one with markup |
| 16:03 | <annevk> | I guess I might lose those features if I switch, hmm :/ |
| 16:03 | <gsnedders> | That's not going to be fun moving with. |
| 16:04 | rubys | is perpetually rewriting his own blog engine, this time in Ruby |
| 16:04 | <gsnedders> | annevk: I'd ask in #habari about keeping things like that |
| 16:05 | gsnedders | has no idea how hard it'd be |
| 16:06 | <rubys> | if you look at blosxom, you can see how easy it can be. And deceptively so. |
| 16:07 | <zcorpan> | annevk: can't the text/plain version be generated from the markup version? |
| 16:07 | hsivonen | notices that IE8's compat view button affects all *.iki.fi subdomains if activated on one. Not good. |
| 16:08 | <annevk> | zcorpan, I suppose, if you have a good fragment parser in place and some logic |
| 16:09 | <zcorpan> | annevk: what logic is needed? |
| 16:10 | <annevk> | expanding abbreviations maybe, dunno, haven't thought about it or studied what I've done so far |
| 16:11 | <hsivonen> | Hixie: is the "parser pause flag" something that's going to stay around once you take into account the script execution model feedback from Apple and Opera? |
| 16:11 | <gsnedders> | annevk: .textContent? |
| 16:11 | zcorpan | wonders if Olivier should take email summaries less literally and try reading the spec instead |
| 16:11 | <annevk> | gsnedders, wouldn't expand abbreviations |
| 16:11 | <gsnedders> | Ah |
| 16:12 | <zcorpan> | why would you want to expand abbreviations? |
| 16:13 | <annevk> | to keep the same info in the text/plain version |
| 16:13 | <annevk> | is this really relevant? |
| 16:13 | annevk | goes back to work |
| 16:24 | <annevk> | I suppose I could consider writing a subset of an XML5 parser (one that ignores DOCTYPES and silly things) and serializer and use that to do my blog, but then I'd still have to fix OpenID support somehow and things like that |
| 16:25 | <rubys> | for your application, why an XML5 parser? Why not simply an HTML5 parser? |
| 16:26 | <annevk> | an HTML5 parser is not simple :) |
| 16:26 | <Philip`> | "import html5lib" |
| 16:26 | <Philip`> | That's easy enough :-) |
| 16:26 | <annevk> | in PHP? |
| 16:26 | <rubys> | why PHP? :-) |
| 16:26 | <zcorpan> | aren't there html5 parsers written in php? |
| 16:26 | <annevk> | that's what I have now and it's rather fast :) |
| 16:26 | <Philip`> | Pipe the text from PHP through an external Python process :-) |
| 16:27 | <Philip`> | It's silly to be constrained by only using a single language at once |
| 16:28 | <jgraham> | annevk: Get a less silly web host? |
| 16:28 | <gsnedders> | annevk: Ping @azyang |
| 16:28 | <hsivonen> | Hixie: the WHATWG spec doesn't have 2009 in the copyright notice |
| 16:28 | <gsnedders> | annevk: Also, PHP is really slow |
| 16:28 | <annevk> | jgraham, DreamHost is not that bad, is it? |
| 16:28 | <annevk> | gsnedders, usually when I do something with Python it's much slower, but I think I get the setup wrong |
| 16:28 | <jgraham> | annevk: Dunno but the specgen was much slower for you on dreamhost than for me on webfaction |
| 16:29 | <annevk> | jgraham, I wonder if it was due to way I configured everything |
| 16:29 | <hsivonen> | PHP--the new COBOL? :-) |
| 16:29 | <jgraham> | annevk: Maybe. But Dreamhost is silly because it only provides really outdated python by default |
| 16:29 | <annevk> | anyway, rewriting everything in Python is even more work :) |
| 16:30 | <annevk> | jgraham, true, though you are allowed to install your own, which sort of offsets that when you figure out how |
| 16:30 | <zcorpan> | "If you want to produce application/xhtml+xml, you are free to do so. If you get it right, no one will notice. If you get it wrong, no one will forgive you." - http://wiki.habariproject.org/en/XHTML_vs_HTML |
| 16:30 | <jgraham> | annevk: Yes but that means you have to install your own which introduces the possibility of configuring it badly |
| 16:31 | <jgraham> | (although I did also install my on on webfaction the default of 2.4.3 is not so bad) |
| 16:31 | <annevk> | fair point |
| 16:31 | <rubys> | zcorpan: I got it wrong once, do you forgive me? :-) |
| 16:31 | <Philip`> | annevk: You don't need to rewrite everything in Python, just use it as a tag-soup-to-DOM conversion tool and import the resulting DOM into PHP |
| 16:31 | <Philip`> | and then you don't have to go to all the effort of implementing an XML5 parser in PHP :-) |
| 16:32 | <gsnedders> | jgraham: What version of Anolis does pms use? |
| 16:34 | <zcorpan> | rubys: no, you need to learn your lesson and stop doing silly string concat :P |
| 16:34 | <jgraham> | gsnedders: 285:0570e687a80b |
| 16:35 | gsnedders | has a vague memory of that being 1.0 |
| 16:35 | <gsnedders> | However, I am wrong |
| 16:35 | <jgraham> | gsnedders: I just pulled the tip |
| 16:35 | <gsnedders> | There's one commit since |
| 16:35 | <jgraham> | That souds wrong, somehow |
| 16:36 | <gsnedders> | tip should be 286 |
| 16:36 | <gsnedders> | 286 changes body to sectioning root from sectioning content (following Hixie's change of HTML 5) |
| 16:36 | <Philip`> | zcorpan: It'd be nice if stopping doing silly string concat let you be certain you were generating well-formed XML, but it never seems to work that well in practice :-( |
| 16:37 | <jgraham> | gsnedders: Yes, that's what I have now |
| 16:37 | <gsnedders> | jgraham: If it breaks the spec, it's Hixie's own fault :) |
| 16:38 | <rubys> | Phillip` +1 |
| 16:38 | <Philip`> | (... e.g. the surrogate-character (I think?) bug in Xalan (I think?) that hsivonen encountered) |
| 16:39 | hsivonen | blames his bozoness on Lotus |
| 16:40 | <rubys> | Meanwhile, I just got http://rails.intertwingly.net/blog/index.html to the point where it renders acceptably on IE8 beta 7000, Opera 9.63, safari 3.2.1, firefox 3.0.5, and chrome 1.0.154.43. WOOT! |
| 16:42 | <olliej> | rubys: i'd be worried if you got something rendering correctly in safari 3.2, but not chrome |
| 16:42 | <olliej> | rubys: given they're both running off the same webkit branch |
| 16:43 | <rubys> | I have some javascript on my weblog... and you can actually see the differences in the two if you look at dates |
| 16:44 | <olliej> | rubys: oh, i assumed you were talking about layout |
| 16:44 | <olliej> | rubys: they have a completely different js engine |
| 16:44 | <rubys> | html5 layout without javascript is broken on IE8 |
| 16:45 | <olliej> | rubys: so their date logic is likely different... although i find myself wondering how date's could vary at all |
| 16:45 | <olliej> | regardless of browser |
| 16:45 | <olliej> | O_o |
| 16:45 | <rubys> | dates are the same, it is the toString and toLocaleString method that differ |
| 16:45 | <annevk> | oh, we have had our share of dates issues as well |
| 16:46 | <annevk> | e.g. getYear and getFullYear iirc |
| 16:46 | <olliej> | morning annevk |
| 16:46 | <annevk> | good afternoon olliej :p |
| 16:46 | <Philip`> | rubys: The "Explore" box on the right has rounded corners but an ugly rectangular border around them, in Opera 9.6something :-( |
| 16:46 | <rubys> | safari: Sunday, January 11, 2009 13:52:02; chrome: Sun Jan 11 2009 13:52:02 |
| 16:47 | <annevk> | does ECMA allow both? |
| 16:47 | <olliej> | annevk: back in nl? |
| 16:47 | <olliej> | annevk: it's ecma |
| 16:47 | <Philip`> | and the comment boxes with rounded corners have a white background behind the cut-out bit of the corner |
| 16:47 | <annevk> | yes |
| 16:47 | <rubys> | Phillip`: that shows a partial svg experiment that I never completed |
| 16:47 | <olliej> | annevk: why would you expect it to define anything? |
| 16:47 | <Philip`> | (rather than the proper background colour) |
| 16:47 | <rubys> | I'll back that out later today |
| 16:48 | <annevk> | olliej, I guess it's naive to assume specs are useful |
| 16:48 | <rubys> | opera has a cool ability to use svg in css, but its usefulness is limited by the fact that you can't do svg inline in css |
| 16:48 | <zcorpan> | rubys: what if IE9 implements createElementNS but doesn't change the parser? |
| 16:48 | <olliej> | annevk: well, esp. ecma262 |
| 16:48 | <rubys> | zcorpan: then I'll react accordingly. |
| 16:48 | <zcorpan> | rubys: but maybe there will be hundreds of people copying your code and won't |
| 16:49 | <annevk> | rubys, E4C? :) |
| 16:49 | <Philip`> | rubys: Konqueror from KDE4 seems to work pretty well too |
| 16:49 | <annevk> | euh, C4X or something |
| 16:49 | <Philip`> | (But I can't test the KDE3 one because somehow it's got totally corrupted) |
| 16:49 | <rubys> | then don't copy my code. :-) |
| 18:04 | <hsivonen> | does Opera 10 have any upcoming CSS features that no other browser has yet? |
| 18:05 | <annevk> | WebKit has SVG as background as well now right? |
| 18:06 | annevk | isn't really sure what exactly is in Opera 10 to be honest |
| 18:06 | <rubys> | Phillip`: I got rid of the rounded corders with square edges on Opera. |
| 18:07 | <rubys> | not sure if this answers hsivonen's question, but opera 9 supports svg as backgrounds in css |
| 18:07 | <annevk> | true |
| 18:07 | <annevk> | we support SVG fonts referenced from @font-face, but I think WebKit has that too |
| 18:10 | <annevk> | of interest here might be "Removed UTF-32 encoding support" |
| 18:10 | <olliej> | annevk: yup |
| 18:10 | <olliej> | annevk: S3.1 has that :D |
| 18:12 | <rubys> | why remove UTF-32 (other than the obvious: nobody uses it)? |
| 18:12 | <hsivonen> | rubys: implementation and QA cost |
| 18:13 | <rubys> | wouldn't have expected either to be that high for something already implemented... |
| 18:14 | <annevk> | just unneeded complexity |
| 18:15 | <annevk> | no need to support more charsets than necessary :) |
| 18:15 | annevk | hopes we can bring it down to some fixed list at some point |
| 18:15 | <annevk> | of course, someone might complain about distributed extensibility when that happens, but we can deal with that :p |
| 18:17 | <Philip`> | annevk: I want <meta charset="http://www.example.com/translation-table-for-my-funky-encoding.xml">; |
| 18:17 | <Philip`> | The existing values can be interpreted as URIs relative to http://www.w3.org/2009/charsets# and it'll all be fine |
| 18:17 | <rubys> | I want utf-8 to be the default, but we can't all have what we want. |
| 18:18 | <annevk> | just include a BOM |
| 18:18 | gsnedders | thinks most people here would want UTF-8 to be default |
| 18:18 | <rubys> | annevk: you are kidding, right? (I hope you are kidding...) |
| 18:19 | <annevk> | rubys, you don't like a BOM? you could use HTTP instead, doesn't really matter :) |
| 18:19 | annevk | wasn't kidding about the fixed list of charsets though |
| 18:19 | <annevk> | and that goal seems sort of realistic |
| 18:19 | <rubys> | I use HTTP's charset. |
| 18:20 | <annevk> | given enough time to investigate what browsers support and ways to lock it down, separate it from OS charset support, etc. |
| 18:20 | Philip` | notes that failing to support encodings can be a security issue |
| 18:21 | <gsnedders> | annevk: Why separate it from OS charset support? Surely that's an extra impl. cost? |
| 18:21 | <annevk> | gsnedders, well, at least have some layer in between that limits or extends what is supported so that it is the same everywhere |
| 18:22 | <gsnedders> | annevk: It just seems like an extra layer for bugs |
| 18:22 | <Philip`> | (e.g. some servers let you select what charset the response will be in, and if you choose one that your victim's browser does not support, you can perform an XSS attack by including safe characters which get encoded into bytes that are decoded by the browser as '<') |
| 18:23 | <annevk> | gsnedders, not supporting the same charsets is also a source of bugs |
| 18:24 | <gsnedders> | Inevitably. Which has the greater cost, though? |
| 18:24 | <annevk> | gsnedders, not supporting the same charsets makes sites unusable... |
| 18:25 | <annevk> | what happened to mr last week btw? |
| 18:25 | annevk | needs his lastweekinhtml5 fix |
| 18:39 | <hober> | http://jacobian.org/writing/descriptivists-and-prescriptivists/ |
| 18:43 | <annevk> | hober, seems we do both, just not fast enough? |
| 18:44 | <hober> | Well, perceived speed and actual speed are probably pretty different in this case... people don't understand what the timeline means. |
| 18:47 | <takkaria> | that article says <canvas> is non-standardised |
| 18:48 | <webben> | well that's true, it isn't standardized |
| 18:48 | <webben> | it's just in progress towards standization. |
| 18:49 | <webben> | though "completely-non-standardized" is over emphatic, perhaps |
| 18:51 | <annevk> | " |
| 18:51 | <annevk> | Look, Flash video is a standard. Every browser under the sun will play a YouTube video. A descriptive view of the web would recognize that Flash has won the web video war, and design a <video> container around that. Instead, we get Ogg. Great." |
| 18:51 | <annevk> | "I want specs that encapsulate how the web actually works, not how a group of academics wish it worked." |
| 18:51 | <annevk> | I guess he meant more than what I summarized above judging from this comment on his own article |
| 18:52 | <rubys> | If you could go back a few years, you could replace that with "Look, IE5 is a standard. Every site under the sun will work with it. A descriptive view of the web would recognize that IE5 has won the web war, and would design a HTML5 standard around that. Instead we get WHATWG. Great" |
| 18:53 | <gavin> | heh |
| 18:53 | <jcranmer> | I know a browser that doesn't play YouTube video |
| 18:53 | <jcranmer> | it's called elinks |
| 18:53 | <gsnedders> | NOWAI |
| 18:53 | <jcranmer> | there's also links, lynx, etc... |
| 18:53 | <jcranmer> | links2, IIRC |
| 18:54 | <rubys> | I downloaded safari yesterday on Windows. It didn't either. I had to install something called a 'plug-in'. |
| 18:54 | <jcranmer> | while I'm in a complaining mood, why won't people make websites look decent in text browsers? |
| 18:54 | <jcranmer> | or even usable? |
| 18:54 | <gavin> | because no one uses text browsers |
| 18:54 | <rubys> | jcranmer: I can't speak for all people, but I can say that I have tried to make my website look decent in text browsers. |
| 18:55 | <jcranmer> | gavin: another way of putting the usability aspect |
| 18:55 | <jcranmer> | don't rely on javascript if you don't have to |
| 18:55 | jcranmer | glares at blackboard |
| 18:55 | <gavin> | "the usability aspect"? |
| 18:56 | <takkaria> | hmm, the author seems to say one needs a balance of prescriptivism and descriptivism, and then in the comments implies that he actually really just wants to be a descriptivist |
| 18:56 | <jcranmer> | making websites usable in text browsers |
| 18:57 | <gavin> | in that case I have no idea what the thing just said to me was supposed to convey |
| 19:30 | <Philip`> | It seems strange to call the WHATWG "a group of academics", since very few members of it are academics |
| 19:32 | <Philip`> | Or is the descriptivist approach to say that the term "academics" simply means "any group of people who I want to insult because they think differently to me"? |
| 19:36 | <annevk> | maybe more like "any group of people who has nice ideas that will never fly in the real world" |
| 19:38 | <Philip`> | annevk: I think that's missing the connotations that the people being referred to are clueless about the real world |
| 19:39 | <Philip`> | (Obviously "real world" is entirely subjective and means "the way I currently view the world") |
| 19:39 | <annevk> | sure, and obviously not everyone thinks our ideas are nice... |
| 20:10 | <tantek> | Philip', "real world" is only entirely subjective if discussed theoretically. if OTOH, one responds to claims of something being (or not being) "real world" with [citation needed] then we can argue based on data/examples/sampling of natural phenomena which tends to better approximate the "real world". |
| 20:21 | <hsivonen> | rubys: for example, Sun's JDK doesn't come with a UTF-32 decoder. It would be silly to require me to write one or to require HTML parsers to require ICU4J to support something no one uses outside of test suites. |
| 20:22 | <hsivonen> | Philip`: supporting encodings is a security issue too. Consider IE and Safari & EBCDIC. |
| 20:24 | <hsivonen> | rubys: I downloaded Windows 7 beta, and IE8 didn't play Flash video out-of-the-box... |
| 20:24 | <rubys> | hsivonen: what you are talking about is subtly different? You are describing what encodings the spec REQUIRES, and the original question was what encodings an implementation choses to implement... |
| 20:25 | <rubys> | I would think that a browser that ran on a mainframe might, for example, support EBCDIC; but I wouldn't mandate that every browser does so. |
| 20:25 | <hsivonen> | rubys: supporting EBCDIC is potentially harmful in a security way. supporting UTF-32 is harmful is an opportunity cost way |
| 20:25 | <annevk> | wouldn't that be bad, because that would mean mainframe content becomes walled gardened |
| 20:26 | <hsivonen> | rubys: I think we should ban all the encoding that we can ban practically |
| 20:26 | <rubys> | good luck with that |
| 20:27 | <rubys> | a parser on a mainframe that can't parse files found on the local hard disk would be only of, ahem, academic interest. |
| 20:27 | <hsivonen> | rubys: why would HTML files on the local drive be EBCDIC rather than e.g. UTF-8? |
| 20:28 | <hsivonen> | rubys: they do have byte-oriented storage, right? |
| 20:28 | <rubys> | because they were produced using ISPF/PDF |
| 20:28 | <rubys> | I programmed on mainframes for over a decade. The short answer to that question is no. |
| 20:28 | <hsivonen> | scary |
| 20:29 | <rubys> | The dominant format for files was (FB 80) which meant that every line took 80 characters, after that point the next line started. |
| 20:29 | <annevk> | but you can put a proxy between the browser and the content |
| 20:29 | <annevk> | rubys, sweet |
| 20:30 | <rubys> | annevk: forget browser for a minute, consider a conforming html5 parser, pointed to a file on a hard disk. |
| 20:30 | <hsivonen> | anyway, it seems to me that it's more up to the mainframe world to interoperate with the rest of the world by developing UTF-8 text editors and byte-oriented storage than up to the rest of the world to complicate stuff to accommodate mainframe peculiarities |
| 20:30 | <annevk> | yeah, NEL and XML 1.1 come to mind |
| 20:30 | <hsivonen> | rubys: I'd want that file to be in UTF-8 regardless of platform. |
| 20:30 | rubys | mutters something about academics and ivory towers |
| 20:31 | <annevk> | rubys, fair enough, but something that fixes the encoding should be possible even on mainframes, right? |
| 20:31 | <hsivonen> | I consider NEL harmful |
| 20:31 | <hsivonen> | rubys: how do mainframes read PNG files? |
| 20:31 | <rubys> | The rest of the world needs to change to accommodate your view of the world. Gotcha. |
| 20:32 | <annevk> | rubys, to a certain extent that is true, yes, people can't write <foo> as root element for HTML documents either, for instance |
| 20:32 | <gavin> | part of the rest of the world needs to change to accommodate the rest of the world |
| 20:32 | <hsivonen> | rubys: like XML changing to accommodate IBM mainframe view of the world? :-) |
| 20:33 | <annevk> | heh |
| 20:34 | <hsivonen> | in retrospect, it wasn't such a great idea to specify SGML in terms of mainframeish "records" and pretend that CRLF magically morphs into record boundaries by fictitious record start/ends getting inserted and immediately removed |
| 20:35 | <rubys> | gavin: a html5 parser on a mainframe reading a text file needs to change to support what? Let's be clear: nobody is arguing that EBCDIC should be REQUIRED. I'm just pushing back on the notion that any encodings can be PROHIBITED. |
| 20:36 | <hsivonen> | rubys: fwiw, I'm OK with an HTML5 parser on a mainframe supporting EBCDIC for local files as long as nothing EBCDIC-encoded ever goes over the HTTP wire |
| 20:36 | <gavin> | I'm suggesting that the mainframe needs to change to support be able to support an html5 user-agent |
| 20:37 | rubys | chuckles |
| 20:37 | <rubys> | One can certainly send XHTML as EBCDIC and have it work with parsers that have installed the right encoding support. |
| 20:37 | <Philip`> | I thought the whole point of it being a mainframe was that it hadn't changed since the 1960s :-) |
| 20:37 | <rubys> | HTTP certainly would not prohibit such |
| 20:38 | <hsivonen> | rubys: that's an interop problem |
| 20:38 | <rubys> | yup |
| 20:38 | <rubys> | So is sending PNGs to lynx. |
| 20:38 | <hsivonen> | in fact, the whole encoding thing is a huge interop loophole in XML |
| 20:39 | <gavin> | I am aware that changing mainframes is not exactly trivial! |
| 20:39 | <annevk> | encoding is a huge interop problem on the Web as well |
| 20:39 | <annevk> | e.g. sites trying to exchange data with each other |
| 20:40 | <rubys> | yup. And I would agree that a BCP (in IETF terms) document describing the set of encodings that are widely supported would be a Good Thing. |
| 20:41 | <hsivonen> | is there a good reason why NEL maps to an Unicode character of its own instead of the EBCDIC to Unicode conversion mapping it to LF? |
| 20:41 | <rubys> | http://feedvalidator.org/docs/warning/ObscureEncoding.html |
| 20:41 | <rubys> | brb |
| 20:42 | <rubys> | back |
| 20:44 | <rubys> | I guessing that NEL is to distinguish between the (uncommonly used but actual) CR and NL characters and the virtual new lines that are inserted between record boundaries. |
| 20:45 | <hsivonen> | how do mainframes deal with the octet-orientedness of IETF protocols? |
| 20:47 | <rubys> | (records consist of octets, but nevermind) Web servers on mainframes certainly support common encodings for interchange. For text files on disk, an EBCDIC to some encoding based on ASCII is performed. For that reason, it would probably be a good idea if HTML5 parsers on a mainframe could process the same files. |
| 20:48 | <hsivonen> | rubys: that's not the kind of area HTML5 tries to be normative about |
| 20:49 | hsivonen | looks up the answer to a similar issue in the context of a theoretical mobile device |
| 20:51 | <hsivonen> | I located the thread: http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0071.html |
| 20:53 | <rubys> | "I don't see how it is practical for HTML 5 to have a blacklist of encodings that should not be supported." +1 |
| 20:53 | <hsivonen> | the reply I wanted to reuse is http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0076.html |
| 21:11 | annevk | reads http://realtech.burningbird.net/semantic-web/semantic-markup/stop-justifying-rdfa "Otherwise, we wouldn't be able to combine documents found on the web with any degree of confidence." and wonders how you can do that without much additional processing to determine whether either or both resources are in fact not spam |
| 21:13 | <takkaria> | it irritates me that RDF's inate logic of subject-predicate was shown to be inadequate in describing the world back in 1892 |
| 21:13 | <hsivonen> | me smiles at 'In other words, begin with the assumption that RDF has value in, and of itself, and does not need to be "justified".' |
| 21:16 | <annevk> | yeah, that's quite a cop out |
| 21:17 | <annevk> | if that were true we should add SMIL support to HTML5... |
| 21:17 | <hsivonen> | as usual, her RDFa example omits the ns decls |
| 21:17 | <hsivonen> | with ns decls, RDF becomes like this: http://www.tbray.org/ongoing/When/200x/2003/12/13/-big/XMLporn.jpg |
| 21:19 | <annevk> | yeah, it's terrible, see e.g. the site linked from http://twitter.com/markbirbeck/status/1112827320 |
| 21:19 | <annevk> | (which also still uses DTDs for some odd reason) |
| 21:20 | <hsivonen> | that's a lot of ontologies minted by one domain holder... |
| 21:21 | <takkaria> | oh, christ |
| 21:21 | <takkaria> | the london gazette site is terrible... |
| 21:25 | <annevk> | the contrast between our efforts to simplify markup and what the XHTML2 WG is up to is striking |
| 21:25 | <annevk> | and might be worth some blog post to highlight the differences at some point :) |
| 21:26 | <Philip`> | It's not really a fair comparison unless HTML5 has a mechanism for expressing the same kind of data |
| 21:31 | <hsivonen> | Philip`: shouldn't the comparison be on the use case and syntax levels? after all, the differences in data expression would be the thing to compare |
| 21:32 | <hsivonen> | that is, presupposing a certain data model defeats the purpose of comparison |
| 21:34 | <Philip`> | hsivonen: Yes - I just mean it'd be unfair to strip out all the xmlns stuff and all the RDFa attributes, and replace it with <!doctype html> and say "look how simple it is now!" |
| 21:35 | <hsivonen> | Philip`: isn't that pretty much what Shelley's example is? |
| 21:35 | <hsivonen> | and RDFa examples in general usually |
| 21:38 | <Philip`> | hsivonen: No idea, I haven't read that blog post |
| 21:40 | <Philip`> | (I'm just responding to the incredulity at the london-gazette site) |
| 21:43 | <hsivonen> | 'There is no confusion about what each of us "means", when use use "subject".' |
| 21:43 | <takkaria> | does anyone know how Google give you the useful links under the first result? |
| 21:43 | <hsivonen> | is there a controlled vocabulary for the values of subject? |
| 21:44 | <hsivonen> | takkaria: partly sitemap, I think, but I guess it's not all sitemap |
