| 02:13 | <Hixie> | anyone have a better idea for a name for the attribute in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10809 than "submitdir"? |
| 02:14 | <Hixie> | we don't really have a good precedent, which is surprising given how many attributes <input> already has |
| 02:15 | <jamesr_> | i thought that was for 'submit directory' |
| 02:17 | <Hixie> | yeah i'm not a fan of "submitdir" as a name |
| 02:17 | <Hixie> | can't think of anything better though |
| 02:18 | <boogyman> | Hixie: "action" seems like a more appropriate verb given the "action" attribute of the form element |
| 02:20 | <boogyman> | then again 'actiondir' isn't fluid either |
| 02:20 | <Hixie> | i don't think the attribute does what you think it does, but it does rather prove my point about "submitdir" being a bad name :-) |
| 02:21 | <karlcow> | hmmm <input> is already for submission somehow. "textdir", "inputdir" could be an option. |
| 02:21 | <Hixie> | it's not setting the value, it's setting a flag to make the client submit the value |
| 02:22 | <boogyman> | Hixie: From the bug, I conclude that it's used to reference the placement of an element after form submission (from a server perspective) |
| 02:22 | <jamesr_> | i thought it was requesting that the client tell the server what directionality the input's data had |
| 02:23 | <Rik`> | exposedir ? |
| 02:23 | <Hixie> | <input name=foo value=bar submitdir> means that instead of just submitting foo=bar, it also submits foo.dir=ltr |
| 02:24 | <karlcow> | dirflag |
| 02:24 | <othermaciej> | submitdir means "please submit the user-set direction of this element in addition to the value" |
| 02:24 | <karlcow> | dirvalue |
| 02:24 | <karlcow> | dirsend |
| 02:26 | <karlcow> | I think othermaciej got it: pleasesubmittheusersetdirectionofthiselementinadditiontothevalue. But it might be prone to errors |
| 02:26 | <Hixie> | also-send-dir="" |
| 02:27 | <jamesr_> | gimmehdir |
| 02:28 | <karlcow> | dir-u-got-me |
| 02:28 | <karlcow> | send-bidi |
| 02:31 | <othermaciej> | the problem with submitdir is that it sounds like it should take a value to use as the direction when submitting the form, a little |
| 02:31 | <othermaciej> | but it is pretty accurate if you don't misparse it that way |
| 02:33 | <Philip`> | <input name="foo" value="bar"><input type="hidden" name="_dir_.foo"> |
| 02:34 | <Philip`> | by analogy with name="_charset_" |
| 02:35 | <karlcow> | <input name="foo" value="bar" registerdir>, <input name="foo" value="bar" putdir>, <input name="foo" value="bar" assertdir> |
| 02:36 | <karlcow> | transmitdir |
| 02:36 | <karlcow> | ok giving up and going back to what I was writing. |
| 02:49 | <MikeSmith> | I notice that http://www.zdnet.co.uk/ has a top-level category for HTML5 now |
| 02:51 | <MikeSmith> | News Reviews Blogs Broadband Cloud DigitalGov HTML Security Windows 7 Apple Google Linux |
| 02:52 | <MikeSmith> | hmm |
| 02:52 | <MikeSmith> | News Reviews Blogs Broadband Cloud DigitalGov HTML 5 Security Windows 7 Apple Google Linux |
| 02:53 | <Philip`> | "HTML 5 will be the development language of the cloud for the next decade." |
| 02:53 | <Philip`> | What's the cloud got to do with it? |
| 02:53 | <Philip`> | I thought the development language of the cloud was various proprietary APIs |
| 02:54 | <boogyman> | Philip`: <insert buzzword> :-s |
| 02:55 | <karlcow> | html5, smoke a joint, code for the cloud |
| 03:01 | <MikeSmith> | I don't see any browser-project people in the attendees list of IETF 79 |
| 03:01 | <MikeSmith> | https://www.ietf.org/registration/ietf79/attendance.py?sortkey=3 |
| 03:04 | <MikeSmith> | but also seems like there are not many especially Web-relevant f2f meetings |
| 03:04 | <MikeSmith> | https://datatracker.ietf.org/meeting/79/agenda.html |
| 03:04 | <MikeSmith> | except for the Web Security WG |
| 03:04 | <MikeSmith> | http://www.ietf.org/proceedings/79/agenda/websec.txt |
| 03:04 | <MikeSmith> | and IRI |
| 03:05 | <MikeSmith> | looks like the Web Security meeting is starting in about 50 minutes |
| 03:06 | <MikeSmith> | Jabber: websec⊙jio |
| 03:06 | <MikeSmith> | Audio: http://videolab.uoregon.edu/events/ietf/ietf797.m3u |
| 03:07 | <MikeSmith> | no real details on the IRI meeting |
| 03:07 | <MikeSmith> | http://www.ietf.org/proceedings/79/agenda/iri.txt |
| 03:08 | <MikeSmith> | …and neither Larry nor Martin are in the list of attendees |
| 03:19 | <MikeSmith> | I wonder if it would be dumb to suggest that they might consider discussing Adam's URL draft |
| 03:19 | <MikeSmith> | https://github.com/abarth/url-spec/raw/master/drafts/url.txt |
| 03:28 | <MikeSmith> | audio for the IRI WG meeting is http://videolab.uoregon.edu/events/ietf/ietf794.m3u |
| 03:30 | <MikeSmith> | and I guess the jabber address is iri⊙jio |
| 03:35 | <MikeSmith> | abarth: http://code.google.com/p/curlies/wiki/RecommendationsForBrowserDevelopers |
| 03:35 | <MikeSmith> | in case there's anything useful in there that's not in your URL draft |
| 03:42 | <abarth> | MikeSmith: thanks |
| 04:30 | <MikeSmith> | abarth: is there a plan for the http-state WG to have a face to face meeting at IETF 80? |
| 04:42 | <abarth> | MikeSmith: i think the http-state WG is basically done |
| 04:42 | <MikeSmith> | oh |
| 04:42 | <MikeSmith> | well that's cool |
| 04:42 | <abarth> | the plan is to go to IETF last call sometime soon |
| 04:42 | <MikeSmith> | great |
| 04:43 | <abarth> | i've been playing around with some improvements to cookies: |
| 04:43 | <MikeSmith> | nice to have an IETF success story |
| 04:43 | <abarth> | http://codereview.chromium.org/4630001/show |
| 04:43 | MikeSmith | reads |
| 04:43 | <abarth> | the basic idea is to have an Origin attribute on cookies |
| 04:43 | <abarth> | that scopes the cookie to an origin |
| 04:43 | <abarth> | the UA sends the cookie back to the server in a new header |
| 04:43 | <abarth> | Origin-Cookie |
| 04:44 | <MikeSmith> | other implementors have interest in this? |
| 04:44 | <abarth> | its basically "Secure cookies done correctly" |
| 04:44 | <MikeSmith> | yeah, I get the basic idea |
| 04:44 | <MikeSmith> | has there been mailing-list discussion about it yet? |
| 04:44 | <abarth> | we've been talking with folks from Mozilla and Apple |
| 04:44 | <MikeSmith> | OK |
| 04:44 | <abarth> | i sent some earlier versions to the http-state mailing list |
| 04:45 | <abarth> | but that was before we figured out how to integrate it with cookies |
| 04:45 | <MikeSmith> | ah |
| 04:45 | <abarth> | it's still very much experimental |
| 04:45 | <abarth> | i'd really like to improve the privacy story for http state management |
| 04:45 | <abarth> | sessionStorage has a nice privacy story |
| 04:46 | <abarth> | we're thinking about using that model to improve privacy |
| 04:46 | <MikeSmith> | I think a lot of people would like to see that privacy story improve |
| 04:46 | <abarth> | the tricky part is we probably wont be able to remove support for cookies |
| 04:46 | <abarth> | as they're pretty popular |
| 04:46 | <MikeSmith> | yeah |
| 04:47 | <MikeSmith> | it's hard to imagine sites migrating away from cookies on a large scale any time soon |
| 04:48 | <abarth> | one thought is that if we provide a viable alternative |
| 04:48 | <abarth> | then you can imagine regulatory or PR pressure |
| 04:48 | <MikeSmith> | oh |
| 04:48 | <MikeSmith> | I would prefer not inviting regulatory pressure |
| 04:48 | <abarth> | :) |
| 04:48 | <abarth> | well, imagine something like Mozilla's privacy icons |
| 04:49 | <abarth> | were you could get a nicer privacy icon if you didn't use cookies |
| 04:49 | <abarth> | that's hard today because there isn't really an alternative |
| 04:49 | <abarth> | but yeah, the privacy parts are a bit of a dream at the moment |
| 04:49 | <abarth> | the security parts are more straightforward |
| 04:50 | <MikeSmith> | I do like the icon ideas |
| 04:50 | <abarth> | i worry that it's like P3P and P3P wasn't an overwhelming success |
| 04:50 | <abarth> | but P3P might have been ahead of its time |
| 04:51 | <MikeSmith> | I think it was, in part |
| 04:51 | <MikeSmith> | I think it also suffered from overengineering |
| 04:54 | <MikeSmith> | and if the only problem were that it was just ahead of its time, then I think we could just start using it now and would not need any alternatives |
| 04:55 | <MikeSmith> | anyway, I wanted to also ask if you plan on publishing your URL parsing doc as an Internet Draft soonish |
| 04:56 | <MikeSmith> | (in the copious amounts of free time you have) |
| 04:56 | <abarth> | yeah, i can do that now |
| 04:56 | <abarth> | it needs a lot of work |
| 04:56 | <MikeSmith> | cool |
| 04:56 | <abarth> | but i think folks would be happier if i uploaded it |
| 05:00 | <MikeSmith> | I would make me happier |
| 05:01 | <MikeSmith> | that's the most important thing :) |
| 05:01 | <MikeSmith> | seriously, I think it would also help the IRI WG work |
| 05:01 | <MikeSmith> | if they are actually going to be working actively |
| 05:02 | <MikeSmith> | hmm, did Alan Kay blog somewhere recently? |
| 05:02 | MikeSmith | finds mention in e-mail of "the recent blog of Alan Kay" |
| 05:02 | <abarth> | dunno |
| 05:54 | <MikeSmith> | Hixie: if you can remember to add the conformance-checker flag for changes that need it, that would be really nice |
| 05:55 | <MikeSmith> | e..g., r5669, for bdi |
| 05:56 | <MikeSmith> | and r5636, for audio attribute on video |
| 06:44 | <Hixie> | MikeSmith: oops, sorry |
| 06:44 | <Hixie> | hm, how about dirname="..." where ... is the field name we end up using |
| 06:44 | <Hixie> | rather than just making it name+".dir" |
| 06:44 | <Hixie> | or dirfield |
| 06:46 | <MikeSmith> | sounds like the name of a place in Illinois |
| 06:46 | <MikeSmith> | or maybe Michigan |
| 06:46 | <MikeSmith> | somewhere up there |
| 06:48 | <MikeSmith> | Icelandic has a very nice short word for "direction" |
| 06:48 | <MikeSmith> | which is "átt" |
| 06:48 | <MikeSmith> | but I guess that doesn't help us much |
| 07:00 | <MikeSmith> | Hixie: only thought I can offer is that it's really about reading order and I think the "dir" abbreviation has always been confusing |
| 07:07 | <MikeSmith> | http://www.theregister.co.uk/2010/11/08/opera_transaction_cache/print.html is a really interesting article |
| 07:13 | <Hixie> | MikeSmith: yeah... dunno which would be more confusing though, using "dir" in there, or _not_ using "dir" in there |
| 07:13 | <MikeSmith> | hmm, yeah |
| 07:39 | <MikeSmith> | Hixie: about r5248, "Make rel=prefetch apply to <a>." |
| 07:39 | <MikeSmith> | you subsequently reverted that at some later point,right? |
| 07:39 | Hixie | looks |
| 07:40 | <MikeSmith> | spec currently allows it on link as well |
| 07:40 | <Hixie> | "The prefetch keyword may be used with link, a, and area elements." |
| 07:40 | <Hixie> | it used to only apply to <link> |
| 07:40 | <Hixie> | it was made to apply to all three |
| 07:40 | <MikeSmith> | ah OK |
| 07:41 | <MikeSmith> | thanks |
| 07:42 | <MikeSmith> | but now I remember that validator.nu is not currently doing any checking on rel values anyway, so I don't need to worry about that one for now |
| 07:44 | <MikeSmith> | hsivonen: as you may or may not have noticed, I just raised a whole bug of new validator.nu bugs for spec changes that Hixie made over the last 4 months |
| 07:45 | <MikeSmith> | http://bugzilla.validator.nu/buglist.cgi?cmdtype=runnamed&namedcmd=open%20bugs |
| 07:45 | <MikeSmith> | about 20 new bugs |
| 07:46 | <MikeSmith> | I think I caught most or all of the changes that would affect validation behavior |
| 07:46 | <MikeSmith> | though not parser behavior |
| 07:47 | <MikeSmith> | anyway, I don't think you need to run your script that auto-generates bugs for spec checkins |
| 07:48 | <MikeSmith> | except maybe for anything that's related to parser behavior |
| 07:52 | <Hixie> | speaking of bugs and scripts, i need to find some way to integrate bugzilla and my mail folders into a single workflow |
| 07:52 | <Hixie> | maybe have the bugmails go to my imap folder and just use that... |
| 07:52 | <Hixie> | let's try that for now |
| 07:56 | <annevk> | Hixie, how about something similar to _charset_? |
| 07:56 | <annevk> | Hixie, and when there's such a hidden input field you will get the direction for all textual-controls |
| 07:57 | <Hixie> | yeah i considered that, but that seems extra complicated, since you'd still have to introduce an attribute to say which control you wanted the direction of |
| 07:57 | <MikeSmith> | annevk: lemme know if I need to do anything about http://lists.w3.org/Archives/Public/public-web-notification/2010Nov/0001.html (Moving Feature Permissions to DAP) |
| 07:58 | <Hixie> | and it doesn't seem to make things any simpler than just having the attribute straight on the control in the first place |
| 07:58 | <annevk> | Hixie, it would give you the direction of all controls where it is needed |
| 07:58 | <annevk> | i.e. it is not needed for <input type=date> but it is needed for <input type=text>, <textarea>, <input type=password> maybe? |
| 08:00 | <Hixie> | oh you'd set this once and it would just generate a whole bunch of fields? |
| 08:00 | <Hixie> | that'd be weird, you almost never actually want the direction |
| 08:00 | <Hixie> | e.g. you wouldn't want it for a password field |
| 08:00 | <hsivonen> | how does form submission on bidi sites work now? |
| 08:00 | <hsivonen> | badly? |
| 08:00 | <Hixie> | not great, yeah |
| 08:01 | <annevk> | Hixie, it would only do it for controls where it is necessary; if it is never needed for password, it would never give it for that one |
| 08:01 | <annevk> | it's just an idea though |
| 08:01 | <Hixie> | well how would you know which it's needed for? |
| 08:01 | <annevk> | it seemed sort of similar to the _charset_ usecase |
| 08:02 | <Hixie> | e.g. it'd be needed for a type=text that is a subject line, but not a type=text that is a credit card number |
| 08:02 | <annevk> | well, I only know it is not needed for <input type=tel>, various date inputs |
| 08:02 | <annevk> | right, for both of those it would give it |
| 08:03 | <annevk> | not sure the overhead would be that big though |
| 08:03 | <Hixie> | i think it'd be better to just have the controls that need it opt into it |
| 08:12 | <annevk> | MikeSmith, I considered going to Beijing, but hybi was not meeting and HTTP was not either |
| 08:12 | <Hixie> | should dirname or submitdir or whatever we call it apply to all input types and just submit the dir="" attribute, or should it only apply to certain types, and submit the element's directionality? |
| 08:12 | <annevk> | MikeSmith, and IRI is a failure so far |
| 08:12 | <MikeSmith> | I see |
| 08:12 | <annevk> | MikeSmith, so it would be for the security stuff and maybe talking to some people, that didn't seem worth it |
| 08:13 | <MikeSmith> | yeah |
| 08:15 | <annevk> | Hixie, I don't think it should apply to date-related input fields |
| 08:15 | <Hixie> | k |
| 08:15 | <annevk> | Hixie, of URL/email?/tel |
| 08:15 | <annevk> | s/of/or/ |
| 08:16 | <Hixie> | .dirname or .dirName |
| 08:16 | <annevk> | should apply to <textarea> |
| 08:16 | <Hixie> | .dirName i guess |
| 08:16 | <annevk> | so it's not a boolean? |
| 08:17 | <Hixie> | nobody understood the boolean name |
| 08:17 | <abarth> | MikeSmith: http://www.ietf.org/id/draft-abarth-url-00.txt |
| 08:17 | <annevk> | but now you need to enter more info |
| 08:17 | <annevk> | rather than name + "dir" or some such |
| 08:17 | <Hixie> | well i can always make it imply the name if you just say "dirname" |
| 08:17 | <Hixie> | if you think that's a problem |
| 08:17 | <MikeSmith> | abarth: cool, thanks for the heads-up |
| 08:17 | <annevk> | that's kind of neat |
| 08:17 | <Hixie> | it'd look weird though |
| 08:18 | <Hixie> | <input type=text required name=subject dirname> |
| 08:18 | <Hixie> | <input type=text required name=subject dirname=subject.dir> |
| 08:18 | <Hixie> | <input type=text required name=subject submitdir> |
| 08:18 | <annevk> | maybe includedir |
| 08:19 | <annevk> | I guess the naming round already happened before I woke up |
| 08:19 | <Hixie> | yeah i considered that but it looks like "included ir" |
| 08:19 | <Hixie> | i should go to bed, but if anyone comes up with a better name while i'm asleep, whether for a boolean attribute or a field name attribute, comment on the bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=10809 |
| 08:20 | <Hixie> | nn |
| 08:25 | <annevk> | MikeSmith, I think DAP will just take over Feature Permissions |
| 08:25 | <annevk> | MikeSmith, nothing really needs to be done |
| 08:26 | <MikeSmith> | great |
| 08:26 | <annevk> | I wonder when the notification documents will be updated |
| 08:26 | <MikeSmith> | by the editor you mean? |
| 08:27 | <annevk> | I wonder why abarth's draft is not on tools.ietf.org |
| 08:27 | <annevk> | takes a while to propagate? |
| 08:27 | <annevk> | MikeSmith, yup |
| 08:27 | <abarth> | yeah |
| 08:29 | <annevk> | so I missed the IRI meeting by an hour |
| 08:29 | <annevk> | oh well |
| 08:29 | <annevk> | oh, it's still going on |
| 08:34 | <annevk> | wow, that's hard to follow |
| 08:56 | <annevk> | also, bidirectional URLs o_O |
| 09:13 | <annevk> | krijnh isn't a sad person either, smiling 22.7% of the time. |
| 09:13 | <annevk> | krijnh is also a sad person, crying 2.1% of the time. |
| 09:13 | <annevk> | something is up |
| 09:29 | <jgraham> | annevk: Maybe he is just bipolar or something |
| 10:22 | <annevk> | yay http://tools.ietf.org/html/draft-abarth-url |
| 11:24 | <MikeSmith> | discussion in comments in http://www.marcozehe.de/2010/11/09/new-accessibility-support-for-html5-elements-and-attributes/ is interesting |
| 11:25 | <MikeSmith> | FF4 is mapping the HTML5 article element to ARIA "main" role |
| 11:28 | <gsnedders> | jgraham: yt? |
| 11:35 | <jgraham> | gsnedders: YEs |
| 11:35 | <MikeSmith> | hmm, so the IME proposal involves adding a getInputContext() method to the HTMLElement interface |
| 11:36 | <MikeSmith> | https://docs.google.com/fileview?id=0B8eVDHQ9_22-MzJhMTg2YmItNWU3NC00NzJmLThlMTAtYmU1ZTBlZWJhNzM0&hl=en&authkey=CLLHkFw&pli=1 |
| 11:39 | <gsnedders> | jgraham: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/692 — evil, or what's better? |
| 11:41 | <jgraham> | gsnedders: I'm not sure what you are trying to achieve |
| 11:41 | <gsnedders> | jgraham: Basically, I have a load of tests which needs the browsing context of an iframe |
| 11:41 | <gsnedders> | jgraham: So I can't run the tests until the iframe has loaded |
| 11:42 | <jgraham> | gsnedders: So create all the test objects |
| 11:42 | <gsnedders> | jgraham: Create a new async test for each? |
| 11:42 | <jgraham> | and then addEventListener("load", function() {test_obj.step(function(){})}, false) |
| 11:42 | gsnedders | sighs |
| 11:42 | <jgraham> | for each test object |
| 11:42 | <gsnedders> | Yay for creating hundreds of test objects. |
| 11:43 | <jgraham> | gsnedders: Well if you want hundreds of tests what do you expect? |
| 11:43 | <jgraham> | It would do it implicitly anyway |
| 11:43 | <gsnedders> | Well, sure, but it seems kinda ugly |
| 11:43 | <jgraham> | just shove them all in an array |
| 11:44 | <gsnedders> | Yeah, will have to do that |
| 11:44 | <jgraham> | tests = []; for (var i=0;i<100;i++) {tests.push(async_test()} |
| 11:44 | <jgraham> | With more brackets |
| 11:44 | <gsnedders> | But it's not awesome when you have to get elements from the DOM from within the iframe |
| 11:44 | <jgraham> | What's not awesome? |
| 11:44 | <jgraham> | And what would be better? |
| 11:45 | <gsnedders> | And the most exact reference you can have within the function is the iframe element |
| 11:45 | <gsnedders> | So you have to have iframe.contentDocument.gEBTN("body"), etc… |
| 11:46 | <jgraham> | You can write the tests inside the iframe document |
| 11:46 | <gsnedders> | Or am I missing an obvious way around this? |
| 11:47 | <gsnedders> | But does that create any event handlers within the iframe document? |
| 11:47 | <gsnedders> | I guess not… |
| 11:47 | <jgraham> | No, just normal cross frame variable access |
| 11:49 | gsnedders | wonders if it's worthwhile testing event handlers for both body and frameset in general |
| 11:49 | <gsnedders> | Or only the things that should differ… |
| 12:46 | <MikeSmith> | for the record, there's been recent discussion about the possibility of adding XSLT 2.0 support to WebKit |
| 12:46 | <MikeSmith> | even before the topic came up last week |
| 12:46 | <MikeSmith> | and unrelated to any discussion of that |
| 12:46 | <MikeSmith> | https://lists.webkit.org/pipermail/webkit-dev/2010-November/015023.html |
| 12:47 | <MikeSmith> | Alex Milowski |
| 12:47 | <jgraham> | Please, no |
| 12:47 | <MikeSmith> | heh |
| 12:48 | <MikeSmith> | you can't stand in the way of progress |
| 12:48 | <jgraham> | XSLT-on-the-web has been a huge waste of time as far as I can see. It is just used enough that you have to support it, but not so much that there is any benefit in doing it well |
| 12:49 | <MikeSmith> | I wonder if jl feels differently |
| 12:50 | <jgraham> | Well he probably enjoyed implementing it :) |
| 12:50 | <jgraham> | As awesome as jl is I don't think the right yardstick for web technologies is "is implementing this an intersting CS problem" |
| 12:51 | <MikeSmith> | :) |
| 12:51 | <MikeSmith> | I suppose so |
| 12:51 | <annevk> | if lots of people were using XML putting more effort in it would make sense |
| 12:53 | <MikeSmith> | maybe the right yardstick should be whether or not there's a cute icon for the technology |
| 12:53 | <MikeSmith> | in which case, http://xqilla.sourceforge.net/HomePage |
| 12:53 | <jgraham> | Oh, so that's why feeds are so widely implemented despite being pretty unpopular ouside tech circles |
| 12:53 | <MikeSmith> | midget dinosaur smashing the crap out of some city |
| 12:53 | <annevk> | haha |
| 12:55 | <hsivonen_> | it would be sad to go on the XPath 2.0 treadmill just because someone integrated some Qt stuff into WebKit |
| 12:58 | <MikeSmith> | the Qt XSLT2 stuff is nowhere near complete |
| 12:58 | <MikeSmith> | but this XQuilla stuff seems to be |
| 13:01 | <hsivonen> | I think demand for XPath 2.0 stuff should first be demonstrated by a JS implementation becoming super-popular |
| 13:01 | <hsivonen> | like jQuery became popular and the Selector API happened |
| 13:11 | <MikeSmith> | I guess that same argument could me made for holding off on natively implementing a lot of other stuff |
| 13:13 | <MikeSmith> | and if there is somebody who has time an interest to integrate it into browser code rather than waiting for somebody else to develop a JS implementation, it would seem pretty odd to stand in the way of them doing that |
| 13:14 | <hsivonen> | MikeSmith: I guess that depends on who is going to maintain it later |
| 13:14 | <MikeSmith> | true |
| 13:14 | <jgraham> | WebIDL needs a comments box :( |
| 13:20 | jgraham | wonders where the restrictions in http://www.w3.org/TR/WebIDL/#native-objects come from |
| 13:21 | <jgraham> | It seems like it is designed to only cover the possibility of passing in a function(){} instead of an object for addEventListener and similar |
| 13:23 | <jgraham> | In particular it seems like it should be possible to allow native objects to be used for ImageData, but the restrictions prevent that |
| 13:24 | <jgraham> | Also, Gecko and current Opera allow that |
| 13:25 | <jgraham> | Also, someone should force heycam to use irssi+screen so I can ramble on here and pretend it counted as useful feedback |
| 13:29 | <annevk> | you could just ramble and expect him to read the logs |
| 13:29 | <jgraham> | What do you think I am doing? |
| 13:30 | <annevk> | just rambling? |
| 13:31 | <jgraham> | Hmm, it seems these days that the stack of open elements is more like a stack of open tokens |
| 13:32 | jgraham | assumes that is what hsivonen implements at least |
| 13:36 | <hsivonen> | jgraham: well, at least the list of active formatting elements contains the data that was on the token |
| 13:38 | <jgraham> | You never have to do an identity comparison between the stack of open elements and the active formatting elements? |
| 13:39 | <hsivonen> | jgraham: that's why the element node reference is also there |
| 13:39 | <hsivonen> | jgraham: so you can compare element node identity |
| 13:39 | <hsivonen> | jgraham: but you never read the attributes from the element node |
| 13:39 | <jgraham> | Oh so you store (token, node) tuples? |
| 13:39 | <hsivonen> | jgraham: you use the attributes from the token |
| 13:39 | <hsivonen> | jgraham: roughly |
| 13:42 | <zcorpan> | http://meteatamel.wordpress.com/2010/11/09/websocket-handshake-and-content-length/ |
| 14:02 | <annevk> | anyone ideas on how to restructure http://dev.w3.org/csswg/cssom-view/ to be more feature-oriented rather than interface-oriented? |
| 14:05 | <erlehmann> | anyone knows if there is en equivalent to a soft hyphen, without a hyphen |
| 14:05 | <erlehmann> | ? |
| 14:05 | <erlehmann> | a soft line break? |
| 14:05 | <annevk> | invisible space |
| 14:05 | <Philip`> | Zero-width space? |
| 14:05 | <annevk> | that one |
| 14:06 | <Philip`> | http://www.fileformat.info/info/unicode/char/200b/index.htm |
| 14:06 | <erlehmann> | annevk, Philip`, thanks. i'll just test it. |
| 14:07 | <erlehmann> | works like a charm! |
| 14:07 | <erlehmann> | :) |
| 14:08 | <annevk> | unexpected victory there :) |
| 14:09 | <Philip`> | I think some browsers and some fonts may render it as a visible little box |
| 14:09 | <Philip`> | but that might have only been IE6 in Wine |
| 14:09 | <Philip`> | so probably best to just test it in whichever browsers/platforms you care about |
| 14:10 | <erlehmann> | I HAVE DONE AN ART |
| 14:11 | <erlehmann> | javascript:function asort(text) {return text.split("").sort().join("\u200b");/* joining with a zero width space makes line breaks possible */}var xPathResult = document.evaluate('.//text()[normalize-space(.) != ""]',document.body,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,null);for(var i = 0, l = xPathResult.snapshotLength; i < l + 1; i++) {var textNode = xPathResult.snapshotItem(i);textNode.data = asort(textNode.data);} |
| 14:11 | <erlehmann> | do this on your favourite website, and it gets sorted. though i have to sort out the alphabetical stuff. |
| 14:13 | <erlehmann> | string.sort() puts "ABC" before "abc" :( |
| 14:35 | <zcorpan> | erlehmann: just pass your own function to sort() that lowercases before comparing |
| 14:35 | <erlehmann> | zcorpan, done. thanks. |
| 14:48 | <erlehmann> | this :) http://daten.dieweltistgarnichtso.net/src/alphabetize.js |
| 14:49 | <jgraham> | erlehmann: You will be glad to know there is a special place in heaven for people who endure the DOM3 XPath APIs |
| 14:50 | <erlehmann> | jgraham, and a special hell for those who invented them. |
| 14:52 | <jgraham> | It's so bad it was considered NSFD (Not Safe For Dante) |
| 15:17 | <hsivonen> | looks like the whatwg wiki needs a higher spec VM |
| 15:18 | <annevk> | VM? |
| 15:18 | <annevk> | oh I see, it's down |
| 15:43 | <annevk> | AryehGregor, you around? |
| 16:40 | <webr3> | http://www.kickstarter.com/projects/seantron/we-are-battle looks cool |
| 16:51 | <annevk> | AryehGregor, wanted to ask feedback on http://annevankesteren.nl/2010/11/html5-bidirectional-text |
| 17:26 | <jdaggett> | joe: ping |
| 17:27 | <Philip`> | jdaggett: (There doesn't appear to be a joe here) |
| 17:27 | <jdaggett> | pardon, wrong room... |
| 19:23 | <grantg> | Is anyone else noticing problems in the chromium implementation of typed arrays? |
| 19:24 | <grantg> | U_U |
| 19:25 | <grantg> | Does anyone else here notice typed arrays are faster in Firefox, but gecko in webkit? |
| 19:25 | <grantg> | *but slower in webkit. |
| 19:25 | grantg | is bad at typing, sorry. |
| 19:25 | grantg | curses out autocomplete |
| 19:26 | <grantg> | oh, shiz, gtg |
| 19:53 | <TabAtkins_> | annevk: What kind of feedback? It seems like you've hit the issues well. |
| 20:29 | <schalkn> | greetings everyone |
| 20:30 | <schalkn> | When refering to HTML5 arguments, does refer to the new one's such as spellcheck, contenteditable etc? |
| 20:31 | <Hixie> | i don't understand the question |
| 20:31 | <MikeSmith> | schalkn: maybe you mean attributes? |
| 20:31 | <schalkn> | One of the tests the IE9 did 'so well' in was HTML5 arguments |
| 20:31 | <schalkn> | What does this refer to exactly? |
| 20:33 | <schalkn> | From the web monkey article: "The W3C test looks at seven elements of HTML5: attributes, audio, video, Canvas, getElementsByClassName, foreigncontent, and XHTML5." |
| 20:34 | <Philip`> | schalkn: Do you mean "attributes" rather than "arguments"? |
| 20:34 | <schalkn> | Ah crap, yes exactly ;D |
| 20:35 | <Philip`> | In this context, "attributes" means http://dvcs.w3.org/hg/html/file/43589d3b48db/tests/approved/attributes/anchor_href.htm |
| 20:35 | <Philip`> | That's the only test case |
| 20:35 | <schalkn> | For example, what does this test do exactly: http://test.w3.org/html/tests/harness/harness.htm |
| 20:35 | <schalkn> | ok, refered to the same thing |
| 20:35 | <Philip`> | The test suite is incredibly incomplete (well under 1% of the number of tests it'll need when it's finished) and the results are meaningless |
| 20:36 | <schalkn> | I was putting something together that uses stuff such as contenteditable, spellcheck, accesskey etc. |
| 20:36 | <schalkn> | And was wondering whether this is what was meant by attributes |
| 20:36 | <schalkn> | it seems so |
| 20:37 | <Philip`> | You should ignore any article that talks about the test suite, because they all seem to be totally missing the point |
| 20:38 | <Philip`> | (the point being that the results are currently meaningless) |
| 20:38 | <Philip`> | In other contexts, "attributes" means lots of different things |
| 20:38 | <schalkn> | ok, note taken |
| 20:40 | <schalkn> | so would the final test include tests against attributes |
| 20:40 | <Philip`> | The hypothetical goal is for the completed test suite to test everything |
| 20:40 | <schalkn> | ok, I see |
| 20:41 | <Philip`> | (or at least everything that's arguably part of HTML, not e.g. CSS) |
| 20:41 | <schalkn> | sure |
| 20:41 | <Philip`> | Need to get people to write the tests before that'll be achieved, though :-) |
| 20:41 | <schalkn> | I am basically working on that here thebrowsereview.com |
| 20:41 | <schalkn> | ;D |
| 20:44 | <MikeSmith> | schalkn: if http://thebrowsereview.com/ is your site,is it OK with you if I add it to our HTML5 aggregator at http://www.w3.org/html/planet/ ? |
| 20:46 | <schalkn> | definitely, that would be great |
| 20:46 | <schalkn> | It is my site |
| 20:47 | <schalkn> | Still a LOT of content that will be going up there. Writing and researching as much as time allows me |
| 20:55 | <jgraham> | schalkn: (insert my standard caution-around-benchmarks note here) |
| 20:58 | <schalkn> | jgraham: bench marks are definitely not perfect and one actually needs to aggregate results from multiple sources, which I hope to do, but over time it does give an indication of the evolution and improvement of say, JavaScript engines |
| 20:59 | <jgraham> | Well yes, if you are doing comparisons like "are engines from 2005 slower than those from 2010" then they are not unreasonable |
| 20:59 | <schalkn> | jip, exactly what I meant |
| 20:59 | <jgraham> | If you are doing "is X faster than Y for real applications" not so much |
| 21:00 | <jgraham> | where X and Y are current browsers |
| 21:01 | <jgraham> | w |
| 21:01 | <schalkn> | The http://dromaeo.com/ tests are pretty good though |
| 21:01 | Philip` | found http://www.tomshardware.com/news/ie9-chrome-firefox-safari-opera,11574.html which seems to be reading a lot into the test results :-/ |
| 21:02 | <schalkn> | Much more intensive and broader than SunSpider |
| 21:03 | <schalkn> | Jip, there were a ton of articles around those test result the last week or so |
| 21:07 | <jgraham> | Not sure that dromeo is particularly good. It tests more than sunspider for sure |
| 21:08 | <jgraham> | Oh man. That Tom's Hardware article |
| 21:08 | <gsnedders> | tl;dr summary? |
| 21:09 | <jgraham> | "OMG the W3C published the HTML5 test results and they say they're not reliable but I am going to take them seriously anyway and make an enormous conspiracy theory out of it" |
| 21:10 | <gsnedders> | Okay. |
| 21:10 | <gsnedders> | Just, okay. |
| 21:10 | <schalkn> | yeah, that is pretty much the gist of it |
| 21:10 | <jgraham> | At least that's what I got from skimming it |
| 21:10 | <jgraham> | I guess I should read it now |
| 21:10 | gsnedders | has better stuff to do here than read such articles on my laptop |
| 21:11 | <jgraham> | But when it starts with "The W3C has spoken, the IE9 is the best HTML5 browser" I don't hold much hope |
| 21:18 | <MikeSmith> | schalkn: added - http://www.w3.org/html/planet/ |
| 21:20 | <schalkn> | Awesome, thanks Mike |
| 21:20 | <schalkn> | Now let me get to work on more content ;D |
| 21:22 | <MikeSmith> | schalkn: it only picked up your "HTML5 Form Elements Browser Support" item, because it doesn't care about CSS or whatever |
| 21:22 | <schalkn> | Ah, ok. Lot more HTML5 stuff coming though |
| 21:23 | <MikeSmith> | great -- it should pick up anything you tag with "HTML5" or anything that mentions HTML5 in the body of the post |
| 21:23 | <schalkn> | perfect |
| 21:24 | <schalkn> | Regarding accesskey, is there some standard being worked towards or suggested that browser vendors will adhere to? I mean, specifying H for home, for example. In IE9, maybe earlier as well, pressing alt+H will move focus to the element with the H accesskey but in others not. The reason being, the not all browsers have implemented access key triggers with Alt+accesskey |
| 21:24 | <schalkn> | There is also the problem that some Alt+ are already mapped to browser menu's and such |
| 21:25 | <schalkn> | I have always found it incredibly hard to make good use of access keys while at the same time making them useful for users and avoiding conflicts with the UA |
| 21:26 | <schalkn> | I completely understand their need and do not foresee it being removed from the spec, but the current implementation is a bit all over the place with regards to browsers. |
| 21:27 | <schalkn> | Thoughts anyone? |
| 21:31 | <jgraham> | """First I noticed that it is a fairly comprehensive and time-consuming test. There are 212 tests [...]""" |
| 21:32 | <jgraham> | That is the scale of the disconnect we have to work through |
| 21:33 | <schalkn> | That is a lot of tests |
| 21:34 | <schalkn> | But heck, there is also a lot of ground to cover |
| 21:34 | <Philip`> | SVG only needed 280 tests, so we're catching up well already |
| 21:35 | <Philip`> | schalkn: 212 is a lot? |
| 21:36 | <jgraham> | schalkn: 212 is a pitiful number of tests compared to the size of HTML5 |
| 21:36 | <schalkn> | Well, the number sound large but see my comment after that. |
| 21:36 | <schalkn> | I thought someone was complaining that, that is to many tests |
| 21:36 | <schalkn> | I personally do not think so |
| 21:36 | <schalkn> | There is a LOT to test |
| 21:37 | <webr3> | 212 is not a low, infact there should be a lot more, and that article is ridiculous |
| 21:37 | webr3 | thinks the writer missed thus HUGE disclaimer |
| 21:37 | <Philip`> | I've got 804 tests just for <canvas>, and that's still missing quite a lot |
| 21:37 | webr3 | s/thus/the |
| 21:38 | <schalkn> | To test HTML5 there will have to be a ton |
| 21:38 | <tabatkins> | "ton" = probably about 100k |
| 21:39 | <schalkn> | Just a quick side not to throw in here(more accesske related stuff). Why is the spec so ambiguous regarding access keys. It seems a bit strange that it can either trigger the link or just move focus to it. Should it not be one of the two? |
| 21:40 | <schalkn> | I mean, if one browser simply moves focus (IE) and another actually activates/follows the link (FF), this can easily become confusing to the end user |
| 21:41 | <schalkn> | So when they are using an access key, they are not sure whether focus will be moved or whether it will follow the link |
| 21:42 | <schalkn> | Maybe it was meant in the context of any HTML element being able to have an access key and some will therefore not be links and as such focus will simply be moved to them |
| 21:42 | <schalkn> | I guess I am answering my own question ;D |
| 21:42 | <Philip`> | Do you mean the bit that says "Each element that can be activated or focused can be assigned a single key combination to activate it, using the accesskey attribute." ? |
| 21:43 | <schalkn> | This bit "All HTML elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element." |
| 21:43 | <Philip`> | That doesn't say "must" (or "should" or other RFC2119 keywords) so it's not a normative requirement - it's just an informative summary of the normative behaviour that's required by other parts of the spec |
| 21:45 | <jgraham> | (technically "may" is a RFC2119 keyword) |
| 21:46 | <jgraham> | (but that sentence isn't relevant to UAs even if you read it as a conformance requirement) |
| 21:46 | <Philip`> | (I was referring more to the bit I quoted, and then was too lazy to bother reading schalkn's quote and updating my response) |
| 21:48 | <Philip`> | I can't actually see a bit that normatively says to focus elements, though |
| 21:50 | <schalkn> | Wait, I am new to reading the specs in depth so please be patient ;D, I read the introduction and I belive I have a better understanding now |
| 21:53 | <Philip`> | It takes a while to get used to the style :-) |
| 21:54 | <Philip`> | I think the most important thing is to be careful to distinguish conformance requirements (things with "must" etc) from everything else |
| 21:54 | <Philip`> | since otherwise there will likely be great confusion |
| 21:54 | <schalkn> | sure, understood |
| 21:54 | <jgraham> | And to distingush author conformance requirements from UA conformance requirements |
| 21:55 | <jgraham> | People often get the first and trip up over the second |
| 21:56 | <Hixie> | http://ln.hixie.ch/?start=1140242962&count=1 might help too |
| 21:56 | <schalkn> | Ah awesome, thanks Ian. Will definitely read that |
| 21:57 | <schalkn> | Quick question, could the text under 8.4.3 Processing model, be seen as something that can form the basis of a test? |
| 22:01 | <othermaciej> | Hixie: btw, I wrote tests for the id element and noticed some things that I wanted to test but couldn't justify based on HTML5 |
| 22:01 | <othermaciej> | Hixie: wanted to ask you about them before I file bugs |
| 22:01 | <Hixie> | sure |
| 22:01 | <Hixie> | schalkn: which processing model is 8.4.3? |
| 22:02 | <schalkn> | For accesskey, not stuck on accesskey, just conveniently located at the moment |
| 22:02 | <schalkn> | http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html?style=highlight#assigned-access-key |
| 22:02 | <jgraham> | schalkn: Yes, but it might be quite difficult to write good tests |
| 22:03 | <Hixie> | it is definitely testable, but as jgraham says, it's a bit of a tricky one |
| 22:03 | <Hixie> | because it is hard to automate |
| 22:03 | <jgraham> | Hixie: That section seems to violate your specification reading guide btw :) |
| 22:03 | <Hixie> | and because the UAs have some leeway |
| 22:03 | <schalkn> | Cool, just want to get a feel for the thinking behind these tests |
| 22:03 | <Hixie> | jgraham: oh? |
| 22:03 | <Hixie> | jgraham: how so? |
| 22:03 | <jgraham> | It is phrased as a statement of fact, but it should be a conformance requirement |
| 22:03 | <Hixie> | jgraham: hm, yes, that section uses 'must' inappropriately |
| 22:03 | <Hixie> | jgraham: it's supposed to be a definition |
| 22:04 | <Hixie> | shouldn't have a "must" in there at all |
| 22:04 | <Hixie> | filed a bug |
| 22:04 | <jgraham> | Ah, OK that would be one fix |
| 22:04 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11279 |
| 22:06 | <othermaciej> | Hixie: the two things I wanted to test are: |
| 22:06 | <othermaciej> | (1) <span id=""> (literally empty value) doesn't create an id association |
| 22:06 | <schalkn> | Wow, I must say I am getting a great insight into the whole spec writing process I do not think a lot of people are aware of. Intense |
| 22:06 | <othermaciej> | (2) what happens when you have multiple elements with the same id |
| 22:06 | <othermaciej> | I guess #2 will be covered by Web DOM Core |
| 22:07 | <othermaciej> | #1 could be fixed by changing an "if" to "if and only if" |
| 22:07 | <othermaciej> | specifically "If the value is not the empty string, user agents must associate the element with the given value" |
| 22:07 | <othermaciej> | if that was "If and only if", I could justify a test for empty id not making an association |
| 22:07 | <othermaciej> | am I reading this right or did I miss a subtletly? |
| 22:08 | <othermaciej> | this is the section I have in mind btw http://dev.w3.org/html5/spec/Overview.html#the-id-attribute |
| 22:10 | <jgraham> | othermaciej: Isn't the "and only if" implied |
| 22:10 | <Hixie> | getElementById() in the face of multiple IDs is a DOM Core issue, but the answer will be to take hte first one in tree order iirc |
| 22:10 | <jgraham> | Because the absence of a specified behaviour always implies the absence of a behaviour |
| 22:10 | <Hixie> | for (1), the spec says "If the value is not the empty string, user agents must associate the element with the given value" |
| 22:10 | <Hixie> | so that seems clear |
| 22:10 | <othermaciej> | jgraham: as a former math geek, I would never assume "if" means "if and only if" |
| 22:11 | <othermaciej> | it seems to me that the spec doesn't say what to do in the empty string case |
| 22:11 | <Hixie> | it's not "only if" because there's a stack of things that could cause the element to have an ID other than this |
| 22:11 | <jgraham> | othermaciej: As a current HTML5 reader you might find it helps :) |
| 22:11 | <Hixie> | e.g. xml:id="" |
| 22:11 | <othermaciej> | it only says what to do in the non-empty-string case |
| 22:11 | <Hixie> | if the spec doesn't tell you to do something, don't do it |
| 22:11 | <jgraham> | So the implication is that in the empty string case you do nothing |
| 22:11 | <Hixie> | i'm not going to list all the things you shouldn't do |
| 22:12 | <Hixie> | because there's an infinite number of them |
| 22:12 | jgraham | tends to agree with Hixie here |
| 22:12 | <othermaciej> | well, the spec certainly doesn't take the position that any implementation with a vendor extension is nonconforming |
| 22:12 | <othermaciej> | so I would have to do mind reading to tell which unmentioned things are secret MUST NOTs |
| 22:12 | <Hixie> | because it explicitly has a "may" for vendor extensions |
| 22:13 | <othermaciej> | is an implementation with a vendor extension to support empty id conforming? |
| 22:13 | <Hixie> | "All extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification." |
| 22:13 | <Hixie> | so no |
| 22:13 | <jgraham> | Arguably it doesn't contradict |
| 22:14 | <othermaciej> | I don't see how it contradicts what the spec says |
| 22:14 | <othermaciej> | it would just define a behavior for the case the spec doesn't define |
| 22:14 | <schalkn> | Thanks for all of the information everyone, cheers |
| 22:14 | <jgraham> | But then neither would it if it caused the default background to blink red and yellow |
| 22:14 | <Hixie> | well you can always define that every element has ID "foo" |
| 22:14 | <Hixie> | i mean, i can't stop that |
| 22:14 | <jgraham> | Which the spec also fails to explicitly forbid |
| 22:14 | <Hixie> | if you just do what the HTML spec says, then you won't assigned an ID for id="" (empty) |
| 22:14 | <Hixie> | if you do other things, you might |
| 22:15 | <Hixie> | the HTML spec just lists the IDs you have to have |
| 22:15 | <othermaciej> | from the position of implementor, I wouldn't assign an ID for empty id |
| 22:15 | <Hixie> | it doesn't prevent you from having other ones |
| 22:15 | <othermaciej> | from the position of test case author, I don't see a justification for testing that |
| 22:15 | <othermaciej> | I'm fine with leaving the test case as is |
| 22:15 | <Hixie> | in particular, xml:id, XML DTDs, and legacy DOM3 Core can all assign IDs in ways outside of HTML's definition |
| 22:16 | <jgraham> | I think you are being more pedantic than is actually usefull :) |
| 22:16 | <jgraham> | s/ll/l/ |
| 22:16 | <othermaciej> | if any element may have any extra ids, for no reason apparent in the markup, then my whole test case is invalid |
| 22:16 | <Hixie> | othermaciej: if you can come up with a way to phrase this that restricts it as we are describing without making an incorrect requirement, i'm all for updating the spec |
| 22:17 | <othermaciej> | well, I can think of how to patch the empty id attribute case, but I am not sure how to properly deal with other sources of ids |
| 22:18 | <othermaciej> | I'll think about it |
| 22:18 | <Hixie> | how would you patch the empty ID attribute case? |
| 22:21 | <othermaciej> | Assuming we are being paranoid about other sources of ids, my first try would be "If the value is not the empty string, user agents must associate the element with the given value ... If the value is the empty string, then user agents must not create an association due to the attribute." |
| 22:21 | <othermaciej> | but then I'd check whether any other means of associating an ID can create an empty ID |
| 22:22 | <zcorpan> | clearly the attribute should be called icanhasdir="" |
| 22:22 | <Hixie> | what if the attribute is missing? |
| 22:22 | <Hixie> | surely if the attribute is missing, then user agents must not create an association due to the attribute either |
| 22:22 | <othermaciej> | anyway, if I think of something good, I'll file a bug |
| 22:22 | <othermaciej> | need to go back to naptime now |
| 22:22 | <Hixie> | also, if the attribute is present, the browser should not crash |
| 22:23 | <Hixie> | and should not make the node in the DOM have an extra invisible parent |
| 22:23 | <Hixie> | and all kinds of other things that the spec doesn't require that you do, but which you could do if you're going down the line of thought that requires you to enumerate the things you should not do... |
| 22:28 | <othermaciej> | I hope HTML5 spells out what should happen in the case of missing or empty-valued attributes in cases where testing that behavior is worthwhile (e.g. the href attribute on <a>) |
| 22:28 | <Hixie> | it spells out what should happen |
| 22:28 | <othermaciej> | you may be right that taking my position to an extreme would lead to the conclusion that no test is valid |
| 22:28 | <Hixie> | it doesn't enumerate what should not happen |
| 22:28 | <Hixie> | id="" is representative of how this is done |
| 22:29 | <Hixie> | throughout the spec |
| 23:35 | <annevk> | fwiw, I hope we can nuke xml:id |
| 23:35 | <annevk> | DOM3 Core methods are nuked by Web DOM Core |
| 23:36 | <annevk> | and dunno about DTD ID assignment, but I hope at some point we can drop that too |
| 23:37 | <Hixie> | yeah in practice it's not as big a deal, those are really just existence proofs more than a real concern |
| 23:42 | <annevk> | I have this idea of introducing Element.id |
| 23:42 | <Hixie> | wfm |
| 23:42 | <annevk> | and Element.class[Name|List] |
| 23:42 | <Hixie> | wfm also |
| 23:42 | <annevk> | great :) |
| 23:43 | <annevk> | the idea being that while maybe we cannot change the syntax layers, we can change the layer that matters |
| 23:52 | <jacobolus> | doesn't Element.id, Element.className already exist? |
| 23:53 | <othermaciej> | annevk: I would love to see xml:id die |
| 23:54 | <annevk> | jacobolus, no |
| 23:54 | <annevk> | hsivonen, feel sorry for the replies you are getting on www-tag |
| 23:57 | <jacobolus> | annevk: those seem to exist in some browsers? |
| 23:57 | <jacobolus> | annevk: or maybe I'm just completely missing the point of the discussion |
| 23:58 | <Hixie> | anne is making the distinction of HTML vs non-HTML Element objects |
| 23:59 | <jacobolus> | so non-HTML elements don't have id/className, but HTML elements do, is that it? |
| 23:59 | <Hixie> | currently |