| 00:00 | <heycam> | jamesr, oh, they should surround the text |
| 00:00 | <sephr> | why does DOMSettableTokenList exist then? |
| 00:00 | <sephr> | I don't see anything that uses it |
| 00:00 | <AryehGregor> | jamesr, on the flip side, it's kind of a pain sometimes to author specs in text/html, like when you forget </ol> and half your document gets silently indented and you don't notice for a week. |
| 00:00 | <TabAtkins> | jamesr: <p>I'm text in a paragraph</p> |
| 00:01 | <AryehGregor> | I kind of wish there were some middle ground. |
| 00:01 | <TabAtkins> | AryehGregor: It's called "use a validator occasionally". |
| 00:01 | <AryehGregor> | sephr, go here (warning, might freeze your browser for a while) <http://www.whatwg.org/specs/web-apps/current-work/#domsettabletokenlist>;, then click on "DOMSettableTokenList" for a list of references in the spec. |
| 00:01 | <jamesr> | AryehGregor: yeah, if the source is html then hopefully the makefile runs a validator for you |
| 00:01 | <AryehGregor> | TabAtkins, peculiar idea. |
| 00:02 | <AryehGregor> | Is there an easily-accessible command-line HTML5 validator around? |
| 00:02 | <sephr> | AryehGregor: didn't help much |
| 00:02 | <sephr> | still se o use of DOMSettableTokenList |
| 00:03 | <sephr> | see no* |
| 00:03 | <AryehGregor> | sephr, I see a bunch. itemRef, itemProp, dropzone, sizes, . . . |
| 00:03 | <sephr> | huh? |
| 00:03 | <sephr> | maybe I didn't click the right stuff |
| 00:03 | <alus> | I have a question about cookies, specifically the domain attribute. is this a reasonable place to ask? |
| 00:04 | <sephr> | oh thanks AryehGregor |
| 00:04 | <AryehGregor> | alus, sure. |
| 00:04 | <sephr> | doesn't make sense to have class and rel lists be non-string-settable though |
| 00:05 | <alus> | the browser already has a cookie I set without specifying "domain". the browser says it's for "foo.com". I tried to set a new cookie for "foo.com", but the browser stored it for ".foo.com". when I visit foo.com it send in the first cookie not the new one |
| 00:05 | <alus> | is this expected behavior? it happens in FF3 and Chrome11 |
| 00:05 | <sephr> | AryehGregor: any insight as to why class and rel lists don't use settable? |
| 00:05 | <sephr> | it's not like you couldn't .add() stuff anyways |
| 00:06 | <alus> | is there any way to store a cookie for "foo.com" by specifying a domain attribute? |
| 00:06 | <aho> | w/o www it's wildcarded |
| 00:06 | <AryehGregor> | sephr, I don't know. My first guess is it's just what existing browsers did before the spec was written, or the spec was written before DOMSettableTokenList, or some similarly prosaic reason. |
| 00:06 | <AryehGregor> | I don't know if they can easily be changed. |
| 00:06 | <sephr> | well it'd only be adding a property and not affecting anything else |
| 00:07 | <aho> | e.g. you can use www.example.com (with cookies for that domain) and put your static files on static.example.com |
| 00:07 | <AryehGregor> | Maybe sites are relying on the existing behavior. |
| 00:07 | <AryehGregor> | I.e., the site might break if assigning a string to the attribute actually worked. |
| 00:07 | <sephr> | it wouldn't change the existing behavior |
| 00:07 | <AryehGregor> | Oh. |
| 00:07 | <AryehGregor> | I see. |
| 00:07 | <aho> | if you don't use www, then cookies will be always sent - even if you request stuff from subdomains |
| 00:07 | <sephr> | nobody references .value in any of their code |
| 00:07 | <AryehGregor> | Yeah, that's a good point. |
| 00:07 | <alus> | aho: that doesn't seem to be true |
| 00:07 | <AryehGregor> | I don't know, then. |
| 00:07 | <AryehGregor> | For classList, you could just use className, right? |
| 00:07 | <AryehGregor> | And there's a similar attribute for rel? |
| 00:07 | <sephr> | yeah, but that's slow |
| 00:07 | <sephr> | .rel |
| 00:08 | <sephr> | would you mind raising this issue on whatever mailing list is appropriate? |
| 00:08 | <AryehGregor> | You can provide spec feedback in the little box. |
| 00:08 | <AryehGregor> | That will file a bug and CC public-html. |
| 00:08 | <AryehGregor> | Why is it slower than setting value? |
| 00:08 | <alus> | aho: if I don't set a domain, it seems to be set for "foo.com" which is *not* sent for subdomains. if I manually set a domain of "foo.com" it's stored for ".foo.com" which *is* sent for subdomains |
| 00:09 | <AryehGregor> | Surely .classList.value and .className are logically identical. |
| 00:09 | <sephr> | it's slower because it has to remove and apply all of the attributes every time you cahnge it |
| 00:09 | <sephr> | AryehGregor: yes they're the same |
| 00:09 | <jamesr> | hmm, somehow the auth failed and it made mercurial get into an infinite loop in urllib. impressive |
| 00:09 | <AryehGregor> | So does setting .value, no? |
| 00:09 | <sephr> | I was talking about the normal API using .add/etc. |
| 00:09 | <sephr> | I'm just wondering why .value doesn't even exist |
| 00:09 | <sephr> | it's just weird |
| 00:09 | <AryehGregor> | jamesr, yeah, Mercurial is fun like that. It also sometimes dies with Python stack traces. |
| 00:10 | <jamesr> | they set the http error listener to retry the connection with no bounds check. new stack frame every time it 401s. very nice |
| 00:10 | <AryehGregor> | Oh, so you mean why doesn't DOMTokenList have a .value attribute to start with? |
| 00:10 | <sephr> | AryehGregor: say you want to pass a DOMSettableTokenList to a function and not an element itself |
| 00:10 | <sephr> | yeah |
| 00:10 | <AryehGregor> | That's a good question, I dunno. |
| 00:10 | <AryehGregor> | It's kind of weird. |
| 00:10 | <AryehGregor> | Definitely feel free to give feedback in the little box, I'd be interested in hearing the question. |
| 00:10 | <AryehGregor> | Or maybe Hixie can tell us right now. |
| 00:10 | <Hixie> | sup |
| 00:10 | <AryehGregor> | Hixie, why does DOMSettableTokenList even exist? Why not just add the .value property to DOMTokenList? |
| 00:11 | <Hixie> | i didn't want there to be two attributes that exposed .className |
| 00:12 | <AryehGregor> | Surely it's less confusing to just use the same interface for everything, though, even if it's redundant? |
| 00:12 | <sephr> | Hixie: yeah, but what if I just want to pass DOMTokenLists? |
| 00:12 | <sephr> | I shouldn't have to pass elements just for those few special cases |
| 00:12 | <AryehGregor> | It's not like it would require extra spec or implementation work to support .value here. |
| 00:12 | <sephr> | where there's already a property |
| 00:12 | <AryehGregor> | It would make the spec shorter, actually. |
| 00:13 | <Hixie> | AryehGregor: i think people won't think of them as the "same interface", they'll think of them as "the way to change X" and "the way to change Y" |
| 00:13 | <Hixie> | sephr: why would you pass a DOMTokenList? |
| 00:13 | <AryehGregor> | I think the status quo is considerably more confusing. |
| 00:13 | <sephr> | hypothetical |
| 00:14 | <sephr> | possibly some fancy js lib |
| 00:14 | <Hixie> | sephr: i try not to fix hypothetical problems :-) |
| 00:14 | <sephr> | well still it's just so much uneeded abstraction |
| 00:14 | <Hixie> | AryehGregor: we need some way to determine which is more confusing, i guess |
| 00:14 | <Hixie> | the design was to avoid redundancy, which i try hard to avoid because it always seems to cause more confusion than it solves |
| 00:14 | <AryehGregor> | Hixie, alternatively, we can just go with the way that's simpler to spec and implement, which is having only one interface. |
| 00:14 | <AryehGregor> | I generally agree that redundancy is bad. |
| 00:15 | <Hixie> | the way that's simpler to spec is the way it's specced now |
| 00:15 | <Hixie> | since to have what we have now requires no change |
| 00:15 | <Hixie> | and to have anything else requires a change |
| 00:15 | <AryehGregor> | Well, okay, yes. |
| 00:15 | <Hixie> | simpler to implement is a different matter, but not as important as what is best far authors |
| 00:15 | <Hixie> | for |
| 00:16 | <Hixie> | without solid data, i don't know how to make the call one way or the other |
| 00:16 | <sephr> | Hixie: for example, say I want to change various DOMTokenList type properties of various elements given a string supplied by a lib user. I shouldn't have to make special exceptions for "classList", etc. |
| 00:16 | <AryehGregor> | sephr, you need to be more concrete. |
| 00:16 | <AryehGregor> | Also, you need to explain why add() and remove() don't work. |
| 00:16 | <sephr> | just did |
| 00:17 | <sephr> | an API being supplied with a string representation |
| 00:17 | <Hixie> | sephr: why would you ever want to do the same thing to classList as to itemProp? |
| 00:17 | <AryehGregor> | Why would such an API even exist? |
| 00:17 | <AryehGregor> | You need to give a realistic and specific use-case, not a hypothetical. |
| 00:17 | <AryehGregor> | Preferably it should be something that you or someone demonstrably wants to do. |
| 00:17 | <sephr> | for the same reason jquery has methods for setting attributes |
| 00:17 | <AryehGregor> | Otherwise, it's not worth the effort to think about. |
| 00:18 | <sephr> | just convenience |
| 00:18 | <AryehGregor> | Does jQuery treat tokenlists differently than everything else? |
| 00:18 | <sephr> | it might if it was easy to |
| 00:18 | <AryehGregor> | Hypothetical convenience is not worth the effort to spec and implement a change. |
| 00:18 | <sephr> | eh, ok |
| 00:18 | <sephr> | Hixie: you can close http://www.w3.org/Bugs/Public/show_bug.cgi?id=12585 |
| 00:18 | <AryehGregor> | There are always going to be more important things to do. |
| 00:19 | <Hixie> | sephr: feel free to close it :-) |
| 00:20 | <sephr> | how? |
| 00:20 | <sephr> | are new users allowed to close any random bugs? |
| 00:20 | <Hixie> | should be able to |
| 00:20 | <AryehGregor> | Anyone with an account can. |
| 00:20 | <sephr> | ok sure |
| 00:23 | <sephr> | hmm |
| 00:23 | <sephr> | not getting the email |
| 00:23 | <sephr> | not even in any spam filters |
| 00:23 | <sephr> | oh nvm got it |
| 00:28 | <jamesr> | heycam: ok, got some stuff up |
| 00:28 | <jamesr> | hmm, i didn't mean to include the native animation stuff |
| 00:28 | <heycam> | yeah if the meat of the spec isn't referencing those definitions, let's leave them out for now |
| 00:29 | <jamesr> | i have definitions without references. oopsie |
| 00:44 | <heycam> | I guess w3c-test.org is an automatic checkout of some repos on dvcs.w3.org? (is w3c-test.org a W3C machine?) |
| 00:52 | <Philip`> | heycam: http://w3c-test.org/ says "W3C would like to thank Microsoft who donated the server that allows us to run this service." |
| 00:53 | <Philip`> | It's automatic except (if I remember correctly) for manual verification of added PHP scripts |
| 00:55 | <heycam> | Philip`, thanks. the non-w3.org domain just looks a bit weird to me. |
| 00:57 | <heycam> | jamesr, also the "getting the next sample time" has lots its definition |
| 00:57 | <Philip`> | heycam: http://lists.w3.org/Archives/Public/public-html-testsuite/2010Nov/0046.html |
| 00:57 | <heycam> | but that probably only made sense when the native animation stuff was in there |
| 00:57 | <jamesr> | yeah it did |
| 00:57 | <heycam> | yes it does, sorry |
| 00:58 | jamesr | looks |
| 00:58 | <heycam> | it needs some definition though |
| 00:58 | <heycam> | Philip`, ah, makes sense |
| 00:58 | <jamesr> | i'm sort of hoping we can define a uniformly monotonic clock on document and define this in terms of that |
| 00:59 | <jamesr> | i think a DOMTimeStamp that's since the unix epoch but that is not directly comparable to Date.now() is going to be bug city |
| 00:59 | <heycam> | yes I agree |
| 00:59 | <jamesr> | there was also some text in your draft about the time between ticks being between 16 and 1000 ms |
| 01:00 | <heycam> | in WebKit you suspend callbacks altogether in background tabs, is that right? |
| 01:00 | <heycam> | ("script-based animations" is also referenced with no definition) |
| 01:00 | <llrcombs> | heycam: I don't believe so |
| 01:00 | <jamesr> | the "MUST be in the future" text in your people.mozilla.org draft is also tricky to resolve with Date.now() |
| 01:00 | <jamesr> | heycam: we do |
| 01:00 | <jamesr> | llrcombs: no? |
| 01:01 | <llrcombs> | example: Chrome web notifications show up when the tab's in the bg |
| 01:01 | <llrcombs> | or did you mean Safari/WK Nightlies? |
| 01:01 | <jamesr> | we're talking about webkitReq uestAnimationFrame |
| 01:01 | <jamesr> | currently those callbacks are completely suspended in background tabs |
| 01:01 | <Hixie> | hsivonen: yt? |
| 01:01 | <jamesr> | or minimized or whatnot |
| 01:01 | <llrcombs> | oh, I just saw "suspend callbacks" |
| 01:01 | <llrcombs> | d |
| 01:01 | <llrcombs> | 'oh |
| 01:01 | <llrcombs> | ignore that |
| 01:01 | <jamesr> | and setTimeout/setInterval timers are clamped to 1s |
| 01:01 | <Hixie> | any xslt people here? |
| 01:01 | <llrcombs> | sorry about that |
| 01:02 | <jamesr> | no worries |
| 01:02 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=11090#c3 seems really surprising to me |
| 01:02 | <heycam> | whether callbacks are suspended entirely or just run very slowly might be something to discuss on the list |
| 01:03 | <heycam> | but I don't mind if the [16,1000] range is missing from the document at the moment |
| 01:06 | <jamesr> | i think the microsoft guys are keen to define the scheduling in terms of vblanks |
| 01:06 | <jamesr> | i don't know where they plan to find a normative reference for that |
| 01:07 | <heycam> | mm |
| 01:07 | <othermaciej> | what's a vblank? |
| 01:08 | <heycam> | the time when the electron gun is moving its focus from the bottom right of the screen to the top left? maybe not a relevant concept any more. :) |
| 01:09 | <heycam> | but the MS guys want callbacks to be run with their animation frame time set to the next 60Hz (or whatever) screen refresh |
| 01:09 | <jamesr> | LCDs still have to copy the pixels from somewhere to screen |
| 01:09 | <jamesr> | and if you manipulate the place it copies from while it's doing the copy you get tearing |
| 01:10 | <othermaciej> | on LCDs it is indeed desirable to update timed with the screen refresh |
| 01:11 | <heycam> | so as well as that, they would like the callback frequency to drop down to 30Hz if it can't keep up with 60Hz |
| 01:11 | <heycam> | rather than having a rate that hovers around, not aligned well with the actual screen refresh rate |
| 01:11 | <jamesr> | that's what many game engines do |
| 01:13 | <heycam> | I think it's a reasonable use case |
| 01:17 | <stevela> | problem occurs when you can definitely keep up with 30hz. When do you decide to go back to 60hz? Game engines will clamp at one or the other as moving back and forth is a worse artifact than just settling at 30hz. |
| 01:17 | <heycam> | yeah |
| 01:17 | <heycam> | you would want some sort of hysteresis so that you don't flip back and forth often |
| 01:18 | <stevela> | Probably want to have the app request a refresh based and the ability to find out what the current vsync interval is. |
| 01:19 | <stevela> | Which of course ratholes due to multiple monitors and moving between them (or spanning them). |
| 01:36 | <TabAtkins> | Hehe: "What's wrong with this declaration (assuming all classes and namespaces are correct)? |
| 01:36 | <TabAtkins> | scoped_ptr<::ppapi::shared_impl::FunctionGroupBase> function_proxies_[INTERFACE_ID_COUNT];" |
| 01:36 | <TabAtkins> | Answer: "<:: is the I Ching trigram for mountain. The angle bracket represents elevation and the two broken lines represent earth. I'd refuse to compile this too -- very inauspicious." |
| 01:37 | <Hixie> | mountain is more like |:: on its side, no? |
| 01:37 | <Hixie> | :-P |
| 01:37 | <Hixie> | (U+2636) |
| 01:38 | <TabAtkins> | Yeah, I noted that too, but hey, it was close enough to be funny. |
| 01:38 | <jamesr> | <:: is a really tall mountain |
| 01:39 | <jamesr> | imagine if html had trigraphs |
| 01:39 | <Hixie> | C's trigraphs are bad enough |
| 01:40 | <Hixie> | let's not go there |
| 01:40 | <heycam> | ??! -- the incredulity operator |
| 01:40 | <jamesr> | trigraphs are what breaks "scoped_ptr<::namespace.." |
| 01:40 | <TabAtkins> | HTML has a quadgraph - <!-- |
| 01:41 | <Hixie> | no, digraphs are what breaks the above |
| 01:41 | <jamesr> | that's a digraph? |
| 01:41 | <Hixie> | <: |
| 01:41 | <Hixie> | means [ in C |
| 01:41 | <jamesr> | >:{ |
| 01:41 | <heycam> | huh, I never knew about those two character diagraphs |
| 01:47 | <jcranmer> | you can disable digraphs in most C compilers, IIRC |
| 02:23 | <jamesr> | do people use the [, arguments] part of window.setTimeout()/window.setInterval() often? |
| 02:28 | <ryanseddon> | it;s not supported in all browsers |
| 02:28 | <ryanseddon> | so pretty much use at own risk |
| 02:28 | <jamesr> | which browsers do not support it? http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers specifies it |
| 02:29 | <ryanseddon> | IE |
| 02:29 | <ryanseddon> | not sure baout 9 or 10 |
| 02:29 | <jamesr> | ok, that's useful to know |
| 02:29 | <ben_alman> | wat |
| 02:29 | <ben_alman> | using optional arguments in setInterval / setTimout would be super cool but it's fail-sauce in IE |
| 02:30 | <ben_alman> | so you kinda avoid it when having to write x-browser code |
| 02:30 | <jamesr> | so people would use it if they could, most likely |
| 02:30 | <ben_alman> | and have to use a closure or partial application |
| 02:30 | <ben_alman> | jamesr, +1 |
| 02:30 | <ben_alman> | BUT |
| 02:30 | <ben_alman> | keep in mind that even if you use opt args |
| 02:30 | <ben_alman> | mozilla has there extra lateness arg |
| 02:30 | <ben_alman> | which totally messes everything up |
| 02:30 | <ben_alman> | http://benalman.com/news/2009/07/the-mysterious-firefox-settime/ |
| 02:31 | <jamesr> | yeah they interfere with adding additional arguments later |
| 02:31 | <ben_alman> | afaict, setTimeout and setInterval are hopelessly fucked |
| 02:31 | <ryanseddon> | long live rAF |
| 02:31 | <ben_alman> | but you could totally use Function#bind |
| 02:31 | <paul_irish> | :) |
| 02:31 | <jamesr> | they are pretty bad but we're doing something sort of similar with requestAnimationFrame and i'm trying to figure out which parts to take |
| 02:31 | <ben_alman> | setTimeout(fn.bind(null, arg1, arg2), 1000) |
| 02:32 | <jamesr> | one guy is saying that he'd like the optional args part of settimeout |
| 02:32 | <ben_alman> | i dunno |
| 02:32 | <ben_alman> | i like passing the extra args from a sugar pov |
| 02:32 | <jamesr> | ben_alman: isn't that just setTimeout(function() {blahblah(arg1, arg2);}, 1000); ? |
| 02:32 | <ben_alman> | jamesr, pretty much, but isn't that pretty much the same thing as args @ the end? |
| 02:33 | <jamesr> | well it works in IE presumably |
| 02:33 | <ben_alman> | polyfill Fn#bind and it works everywhere regardless of Moz or IE, right? |
| 02:33 | <ryanseddon> | yep |
| 02:33 | <ben_alman> | because the lateness arg and the IE borked-ness would become a non-issue |
| 02:34 | <ben_alman> | i've created jQuery plugins (etc) that have optional args @ the end |
| 02:34 | <ben_alman> | which is nice |
| 02:34 | <ben_alman> | for sure |
| 02:34 | <ben_alman> | but because of setTimeout / setInterval it's tough to say "we're making it like these" since they have x-browser issues |
| 02:37 | <ben_alman> | ok, time to roll |
| 06:04 | <ben_h> | ! |
| 06:37 | <Hixie> | a number of people replying to the survey on the licenses seem to lack understanding of how the w3c patent policy works, which is odd |
| 06:37 | <jamesr> | people on the internet do not understand things as well as they think they do? why does that seem odd to you? |
| 06:38 | <Hixie> | because the people who don't understand it seem to have strong views on the matter and should know better |
| 06:39 | <jamesr> | has the w3 ever sued anyone over copyright violation? |
| 06:39 | <Hixie> | not to me knolwedge |
| 06:39 | <Hixie> | but it has a chilling effect |
| 06:42 | <hsivonen> | When I got a copyright warning from the W3C, I sure felt chilled until the warning was retracted a few minutes later. |
| 06:42 | <Hixie> | right |
| 06:42 | <Hixie> | oh hey, hsivonen is here |
| 06:42 | <Hixie> | hsivonen: see the xslt bug |
| 06:43 | <Hixie> | hsivonen: let me know if it's ok |
| 06:43 | <jamesr> | yeah it's disappointing |
| 06:43 | <Hixie> | hsivonen: it's not normative, the task of defining it sufficiently to get the effect you want normatively seemed a bit daunting |
| 06:43 | <hsivonen> | Hixie: the diff looked OK. A bit worrying that it prescribed one thing I consider a bug in Firefox, but since we aren't planning to fix that bug, I'm OK with it. |
| 06:43 | <Hixie> | happy to change it, especially since it's just descriptive and not normative |
| 06:44 | <hsivonen> | Hixie: nah. let's leave it like that |
| 06:44 | <Hixie> | k |
| 06:44 | <hsivonen> | as descriptive it's now entirely accurate |
| 06:45 | <hsivonen> | Hixie: thanks |
| 06:45 | <hsivonen> | I hope the next implementor appreciates the note |
| 06:45 | <Hixie> | np |
| 06:45 | <Hixie> | yeah, hope so |
| 06:45 | <hsivonen> | I sure wish it had been in the spec when I implemented |
| 06:45 | <Hixie> | yeah, sorry about that. xslt isn't on my radar. |
| 06:52 | <tw2113> | about what you're looking for? |
| 06:52 | <tw2113> | wrong room, my bad |
| 09:44 | <smaug____> | when is anne coming back? |
| 09:44 | smaug____ | hopes someone will specify caretRangeFromPoint properly |
| 09:45 | <jgraham> | smaug____: s/someone/anne/? |
| 09:45 | <jgraham> | End of the month, I think |
| 09:45 | <smaug____> | jgraham: ok, thanks |
| 09:46 | <smaug____> | jgraham: well, it is "anne's" spec, where it is currently specified |
| 09:47 | <smaug____> | er |
| 09:47 | <smaug____> | aha |
| 09:47 | <smaug____> | it has been replaced in the latest editor's draft |
| 09:47 | smaug____ | accidentally looked at WD |
| 09:48 | <jgraham> | smaug____: You lose 10 W3C points |
| 09:48 | smaug____ | blames bug reported |
| 09:48 | <smaug____> | reporter |
| 09:49 | <jgraham> | Oh, anne is actually back a bit later than I thought |
| 09:49 | <jgraham> | But anyway |
| 13:29 | <sgentle> | hiya |
| 13:29 | <Philip`> | Hello |
| 13:33 | <sgentle> | would this be a good place to ask obscure questions about the different browser implementations of canvas global compositing? :D |
| 13:33 | <Philip`> | Yes :-) |
| 13:33 | <sgentle> | I was hoping you'd say that :D |
| 13:34 | <sgentle> | alright, so my use case is I have a canvas that I'd like to apply an 'eraser tool' style effect to |
| 13:34 | <sgentle> | there's stuff under the canvas, so I can't just draw white over it, I need to draw transparent |
| 13:34 | <sgentle> | aka the 'copy' composite operation |
| 13:35 | <sgentle> | in webkit browsers that works fine, because they restrict the scope of the operation to the area being drawn |
| 13:36 | <Philip`> | Yeah, WebKit doesn't match the spec |
| 13:37 | <sgentle> | *nod* and the spec seems to say the right thing to do is for the scope to be the clipping area |
| 13:37 | <Philip`> | Yep |
| 13:37 | <sgentle> | which is cool, except... is there a way to do what I want to do using the spec-compliant way? |
| 13:38 | <Philip`> | How are you drawing your tool? |
| 13:38 | <Philip`> | If it's an outline that you fill() then you could clip() to it first and then clear, I think |
| 13:39 | <sgentle> | yeah, I'm trying that at the moment |
| 13:39 | <sgentle> | but the spec says when you clip() it intersects with the old clipping area |
| 13:39 | <Philip`> | Why is that a problem? |
| 13:40 | <Philip`> | (You can save()/restore() to fix the clipping region afterwards) |
| 13:40 | <sgentle> | oh right |
| 13:41 | <sgentle> | ...you keep anticpating what I'm typing, is that a special whatwg power? :) |
| 13:41 | <Philip`> | Telepathy is an experimental feature in HTML6 |
| 13:43 | <Philip`> | I don't think there's any way to clear non-rectangular shapes other than via clipping, or manually with get/putImageData |
| 13:44 | <Philip`> | but hopefully clipping is powerful enough for most needs |
| 13:48 | <sgentle> | aww, look at that, works perfectly now |
| 13:49 | <sgentle> | thanks so much |
| 13:51 | <sgentle> | dunno why, I just skipped over "save" and "restore" thinking they were about image data... even though I already new about get/putImageData |
| 13:59 | <Philip`> | sgentle: They're about pretty much everything *except* image data |
| 18:42 | <hij1nx> | does anyone know of an html5 parser in c++? |
| 18:42 | <jcranmer> | gecko's HTML parser? |
| 18:42 | <AryehGregor> | hij1nx, Mozilla uses one. |
| 18:42 | <AryehGregor> | Grr, Chrome just lost all my open tabs on upgrade and restart. >:( |
| 18:43 | <jcranmer> | (well, technicaly it's written in Java, converted to C++ automatically, and then hand-tweaked for better performance) |
| 18:43 | <jcranmer> | but I digress |
| 18:43 | <AryehGregor> | And I see no way to get them back. Oh well. |
| 18:44 | <hij1nx> | AryehGregor: curious about dependencies |
| 18:44 | <AryehGregor> | hij1nx, no idea, sorry. |
| 18:44 | <hij1nx> | AryehGregor: =) |
| 18:45 | <hij1nx> | jcranmer: from what i understand, there are deps on jsc |
| 18:46 | <hij1nx> | jcranmer: sorry, i read gecko and thought webcore ;) |
| 18:49 | <Ms2ger> | hij1nx, hsivonen has at least thought about releasing a C++ HTML parser, IIRC |
| 18:49 | <hij1nx> | Ms2ger: i just found this in a google search... http://www.netsurf-browser.org/projects/hubbub/ |
| 18:50 | <hsivonen> | indeed, it's planned and ok'ed by Mozilla. I just need to take a break from Gecko work to do it. |
| 18:51 | <hij1nx> | does anyone have any opinion on this? (http://www.netsurf-browser.org/projects/hubbub/) |
| 18:52 | <hsivonen> | jcranmer: it's not really "hand-tweaked for better performance" after the translation, FWIW |
| 18:52 | <jcranmer> | hsivonen: I thought there were a few patches applied only to the C++ end |
| 18:52 | <jcranmer> | I could be recalling wrong |
| 18:53 | <jcranmer> | gecko is not my main cup of tea |
| 18:53 | <hsivonen> | jcranmer: there are some minor differences between Java and C++ but they are baked into the translator, so there's no patching of the translator output |
| 18:53 | <jcranmer> | ah |
| 18:54 | <jcranmer> | same basic idea |
| 18:54 | <hsivonen> | the main differences are: |
| 18:54 | <hsivonen> | 1) the named character data layout is generated separately so that tables aren't translated from the Java tables |
| 18:55 | <hsivonen> | 2) in the near future, the C++ version will have two copies of the tokenizer loop: one with error reporting and one without |
| 18:55 | <hsivonen> | (the goto stuff turned out to be slower than the switchiness, so I threw it away) |
| 18:56 | <jcranmer> | I'm not surprised |
| 18:57 | <jcranmer> | switch statements are probably more aggressively optimized than gotos |
| 18:57 | <hsivonen> | I suppose so |
| 18:57 | <jcranmer> | on the basis that people actually use switch statements |
| 18:57 | <hsivonen> | :-) |
| 19:15 | <TabAtkins> | othermaciej: Doesn't the fact that Ian's diff is different from Rich's qualify as an objection from Ian? |
| 19:15 | <othermaciej> | TabAtkins: I prefer not to make assumptions |
| 19:16 | <Orbixx> | Just had an interesting idea. |
| 19:16 | <othermaciej> | of anyone (Ian, you, or anyone else) thinks Rich's diff is inconsistent with the decision or contains changes not actually required by the decision, they can say so |
| 19:16 | <Orbixx> | It's debatably redundant, due to TLS, but here it goes. |
| 19:17 | <AryehGregor> | TabAtkins, logically it shouldn't imply that. Maybe he thinks that there are multiple legitimate ways to read the decision. |
| 19:17 | <Orbixx> | An option for <input> for password fields, where a hash type can be specified in the tag so that the browser hashes the password before sending it to the webserver. |
| 19:18 | <TabAtkins> | Orbixx: If the attacker can snoop, they can probably MITM you as well and just alter the page in-flight to the user to not have the hash, and then alter the response back to the server to have the hashed data. |
| 19:18 | <AryehGregor> | Orbixx, can be done pretty easily in JavaScript. Is it really widely enough done that there's a need for a declarative feature? |
| 19:19 | <AryehGregor> | TabAtkins, it works against passive MITMs, which is a valid use-case. |
| 19:19 | <AryehGregor> | Passive MITM is often less risky or easier than active MITM. |
| 19:19 | <hij1nx> | is anyone familiar with libDOM? |
| 19:19 | <Orbixx> | TabAtkins: Assume the network is secure against active MITM. |
| 19:19 | <Orbixx> | Which established networks are. |
| 19:20 | <Orbixx> | You know, and other unlikely stuff. |
| 19:20 | <AryehGregor> | Orbixx, usually if you can do passive MITM, you can do active too. |
| 19:20 | <AryehGregor> | If you can read the packets, you're presumably intercepting them somehow and can change them. |
| 19:20 | <AryehGregor> | Maybe not in some Wi-Fi scenarios, not sure about that. |
| 19:21 | <Orbixx> | Mmm, that's true. |
| 19:21 | <TabAtkins> | In many open wifi scenarious, you can alternately just broadcast yourself as a hotspot and act as a MITM proxy. |
| 19:21 | <AryehGregor> | Right, but you're always much more likely to be detected if you tamper with anything, so passive-only MITM is still a valid use-case. |
| 19:21 | <AryehGregor> | I just don't think it's important enough to justify a declarative feature for something that's trivial to do from script. |
| 19:21 | <Orbixx> | Hmm. |
| 19:21 | <AryehGregor> | vBulletin does this from script, for example. |
| 19:22 | <Orbixx> | Okay, assume this isn't intended to combat MITM. |
| 19:22 | <Orbixx> | What about... |
| 19:22 | <AryehGregor> | Special markup is only a good idea if it would be very widely useful. |
| 19:22 | <Orbixx> | Assume HTTPS, but it's to protect against |
| 19:22 | <Orbixx> | Wait, nevermind. |
| 19:22 | <Orbixx> | That's also stupid. |
| 19:22 | <Orbixx> | :D |
| 19:22 | <Orbixx> | Oh well. |
| 19:22 | <AryehGregor> | Sounds like you're starting with a feature and then trying to think of uses. That's not a good way to go about things. |
| 19:22 | <Orbixx> | Just a thought. |
| 19:22 | <AryehGregor> | Start with "I want to do X but the existing ways all have problems". |
| 19:22 | <AryehGregor> | A concrete use-case. |
| 19:22 | <Orbixx> | Yeah, fair comment. |
| 19:23 | <AryehGregor> | People are not usually interesting in writing specifications and code for features that aren't demonstrably useful in real life. |
| 19:23 | <Orbixx> | It's very rare I actually come up with an idea, so I'm not used to the critical thinking that comes with it :P |
| 19:23 | <AryehGregor> | No problem. |
| 19:23 | <AryehGregor> | I've thought of the same feature, I think. |
| 19:24 | <Orbixx> | Kind of why I came here, I expected exactly what I got. |
| 19:24 | <Orbixx> | Criticism that would tell me why it's a stupid idea :P |
| 19:24 | <AryehGregor> | Happy to oblige. :) |
| 19:26 | <Orbixx> | Got a little bit excited about contributing to HTML specification for a brief moment. |
| 19:26 | <Orbixx> | I'll return with yet another brilliant yet flawed concept soon, no doubt. |
| 19:29 | <AryehGregor> | Looking forward to it! |
| 20:05 | <AryehGregor> | If you had the markup <ol><li>foo<br>bar<li>baz</ol>, and selected "foo" and ran an "indent" command, what would you expect to happen? |
| 20:06 | <AryehGregor> | I'm observing six different behaviors in six different programs. |
| 20:06 | <TabAtkins> | I expect another list to be created. |
| 20:06 | <TabAtkins> | Dunno whether I'd expect ol or ul. |
| 20:06 | <Ms2ger> | Wrap it in a blockquote? :) |
| 20:07 | <AryehGregor> | TabAtkins, like <ol><li><ol><li>foo</ol>bar<li>baz</ol> or something? |
| 20:07 | <Hixie> | set a class on it and have a style rule added that adds some padding? :-) |
| 20:07 | <AryehGregor> | Ms2ger, correct for Firefox with styleWithCSS true! |
| 20:07 | <TabAtkins> | AryehGregor: I guess. Is there a more targetted "make a list" command than "indent"? |
| 20:07 | <AryehGregor> | TabAtkins, yes, there are also insertOrderedList and insertHorizontalList. |
| 20:07 | <AryehGregor> | Those tend to toggle the list, if there's one already. |
| 20:07 | <TabAtkins> | Oh, hmm then. |
| 20:08 | <AryehGregor> | (the six different behaviors in six different programs are actually because Gecko and OpenOffice.org both exhibit two different behaviors depending on which commands you use) |
| 20:08 | <Ms2ger> | AryehGregor, hey, that was best practice in '96 ;) |
| 20:08 | <AryehGregor> | Ms2ger, well, it's also what most browsers do for indent outside of lists. |
| 20:08 | <AryehGregor> | Since you haven't selected the whole <li>, Gecko seems to just ignore the fact that you're in a list. |
| 20:09 | <TabAtkins> | If indention is usually done by blockquote, I guess just keep with the blockquoting. |
| 20:09 | <AryehGregor> | But normally, indenting inside a list nests a list, like <ol><li>foo<li>bar<li>baz</ol> -> <ol><li>foo<ol><li>bar</ol><li>baz</ol> (if "bar" is selected). |
| 20:10 | <AryehGregor> | Anyway, I'm not really trying to collect data here, I was just amused by the wild discrepancies. |
| 20:10 | <TabAtkins> | Mapping GUI idioms to semantic code is hard. |
| 20:10 | <AryehGregor> | I don't care about the semantics, I'm only looking at the visible output. |
| 20:11 | <AryehGregor> | This is a WYSIWYG API, after all. |
| 20:11 | <AryehGregor> | There are six different behaviors just in the visible output. |
| 20:11 | <AryehGregor> | (I mean, I care about semantics somewhat, but the API really is entirely presentational by design, so producing semantic markup is not a possible design goal) |
| 20:12 | <AryehGregor> | (Of course I care about semantics in general, just not much in the case of execCommand()) |
| 20:12 | <Hixie> | AryehGregor: 6 for 6 is pretty bad. i did once have 4 different behaviours for 3 browsers, though (iirc that was a quirks mode thing) |
| 20:12 | <erlehmann> | urgs |
| 20:12 | <AryehGregor> | Hixie, if I didn't test IE or Opera in this case, I'd have six behaviors for four programs. :) |
| 20:13 | <Ms2ger> | Hixie, I thought it was a version thing |
| 20:13 | <TabAtkins> | At least you know that you can spec anything you want. That's some nice freedom there. |
| 20:13 | <Hixie> | oh, yeah, i've definitely had it for multiple versions of the same browser, too |
| 20:13 | <Hixie> | TabAtkins: indeed |
| 20:13 | <AryehGregor> | (IE and Opera agree with Firefox's non-CSS mode, which is roughly <ol><ol><li>foo<br>bar</ol><li>baz</ol>) |
| 20:13 | <TabAtkins> | Hell, you can spec an entirely new behavior and only be inconsistent with 16% more implementations than otherwise. |
| 20:13 | <AryehGregor> | Yeah, I'm trying to work out a mental model for lists that makes sense for users. |
| 20:14 | <AryehGregor> | And apply it consistently. |
| 20:14 | <Ms2ger> | glwt |
| 20:14 | <TabAtkins> | Wait, what? <ol> as a direct child of <ol>? |
| 20:14 | <AryehGregor> | Yes. |
| 20:14 | <TabAtkins> | Awesome. |
| 20:14 | <AryehGregor> | Every browser will do that in some case here, I think. |
| 20:15 | <Ms2ger> | TabAtkins, obviously, you don't want the bullet ;) |
| 20:15 | <AryehGregor> | It's the only logical way to get a visual effect like "\t\ta. foo\n\t1. bar". |
| 20:15 | <AryehGregor> | So it's the natural thing to do if the user does indent on something like <ol><li>foo</ol>. |
| 20:15 | <AryehGregor> | Just do <ol><ol><li>foo</ol></ol>. |
| 20:15 | <AryehGregor> | Of course, such a list makes no semantic sense, so is deservedly invalid. |
| 20:18 | <AryehGregor> | This testing is time-consuming. |
| 21:00 | <TabAtkins> | Wait, what? "you are challenging the purpose of ARIA itself, and related, WCAG |
| 21:00 | <TabAtkins> | standards. These are required by U.S. law, and their absence is an active |
| 21:00 | <TabAtkins> | attempt at stifling competition. |
| 21:01 | <AryehGregor> | Have I remarked before that Change Proposal-mediated arbitration is probably the only way to make progress in the HTMLWG on a11y issues? |
| 21:01 | <TabAtkins> | Not in my company. |
| 21:02 | <AryehGregor> | Ooh, ooh, I got something that has different behavior in every one of the programs. |
| 21:02 | <AryehGregor> | One behavior per program. |
| 21:03 | <AryehGregor> | In <ol><li>foo<li>bar<ol><li>baz</ol><li>quz</ol>, select "bar" and click the unordered list button (or do insertUnorderedList for browsers). |
| 21:06 | <Ms2ger> | "progress" |
| 21:07 | AryehGregor | thinks Opera is correct on that one, given the constraints browsers face |
| 21:07 | <AryehGregor> | Word and OO seem to not mind having one list with some items bulleted and some numbered. |
| 21:42 | <bckenny> | hihihihi |
| 21:42 | <bckenny> | whoops, sorry about that |
| 22:05 | <TabAtkins> | Hixie, I really wish you'd not just do whatever the trolls ask to the W3C spec. |
| 22:10 | <karlcow> | TabAtkins, everyone can be the troll of someone else. Welcome to the new Class struggle |
| 22:10 | <TabAtkins> | Don't try and pull that relativism line on me. ^_^ |
| 22:11 | <karlcow> | TabAtkins, I'm not trying. I'm asserting (for once) |
| 22:11 | <TabAtkins> | Okay, then don't assert that relativism line. |
| 22:12 | <karlcow> | fascism ;) |
| 22:12 | <TabAtkins> | I... don't understand the reference. Also, did you just Godwin yourself? |
| 22:13 | <karlcow> | you mention godwin, not me and you asked me to "do not" |
| 22:13 | <TabAtkins> | I'm even more confused now. |
| 22:14 | <karlcow> | I can see that. |
| 22:14 | <TabAtkins> | Sigh. |
| 22:15 | karlcow | was just saying that many of the schisms in HTMLWG are due to conflicts driven by school of thoughts, ideas of society, and generations. |
| 22:15 | <karlcow> | not trolls |
| 22:15 | <Ms2ger`> | karlcow, I wish I could believe you |
| 22:17 | <TabAtkins> | I don't care about the differences in thought - those are natural and fine. I care about the trollish behavior, starting with the Decision Process that Shelley got instituted, which has now successfully made it too expensive to care what happens to the spec for most of the useful people. |
| 22:17 | <karlcow> | I have, for example, stopped participating mostly in discussions about html5, because people categorize others as trolls, or pickup your own $preferredexclusion mode. |
| 22:18 | AryehGregor | more or less agrees with karlcow |
| 22:18 | <AryehGregor> | I don't think anyone is trolling in the HTMLWG, as a matter of course. |
| 22:18 | <AryehGregor> | Anyone who thinks otherwise is erroneously assuming bad faith. |
| 22:18 | <AryehGregor> | All the active participants are genuinely trying to improve the spec. |
| 22:18 | <AryehGregor> | Trolling would be if they just wanted to annoy people, and didn't care about the spec. |
| 22:19 | <Philip`> | What if they care about the spec *and* want to annoy people? |
| 22:19 | <TabAtkins> | I consider active use of the Decision Process to be trolling, basically. ^_^ |
| 22:19 | <karlcow> | Philip`: I still have to meet this person then. |
| 22:19 | <AryehGregor> | TabAtkins, that amounts to using the term "troll" to refer to anyone you disagree with. |
| 22:19 | <AryehGregor> | Which is common usage, but not very productive. |
| 22:20 | <TabAtkins> | AryehGregor: Certainly not. That implies that I disagree with every issue ever raised via the Decision Process. |
| 22:20 | <AryehGregor> | Or that you disagree with the idea of using the Decision Process regardless of the issue's merits. |
| 22:21 | <TabAtkins> | Bingo. |
| 22:23 | <TabAtkins> | (I happen to disagree with *most* of the issues that have been through the Decision Process, but certainly not all. I still disapprove of the use of the DP on the issues I agree with.) |
| 22:32 | <zcorpan> | Hixie: do all elements now have ids of the form the-foo-element? |
| 22:32 | <Ms2ger`> | Should be that way |
| 22:32 | <zcorpan> | yay |
| 22:33 | zcorpan | fixes html-elements |
| 22:37 | <zcorpan> | ah, need to wait for ben to regen developers.whatwg.org |
| 22:42 | <zcorpan> | Hixie: fwiw and as someone who maintains links to elements in the spec, the id change is really good. not having to scrape the spec to know what the id is for an element is a huge win |
| 22:42 | <zcorpan> | although i also maintain links to attributes |
| 22:43 | <Hixie> | TabAtkins: object to it and the chairs will require me to revert it |
| 22:43 | <TabAtkins> | I did now. |
| 22:43 | <Hixie> | zcorpan: cool |
| 22:44 | <Hixie> | zcorpan: file a bug saying which attributes need updating like jirka did for the elements and i'll fix them too :-) |
| 22:48 | <zcorpan> | oops. i accidentally all the attribute links in html-elements |
| 22:48 | <Ms2ger`> | ALL of them? |
| 22:49 | <benschwarz> | zcorpan: Regenerated |
| 22:49 | <benschwarz> | Deployed. |
| 22:49 | <zcorpan> | Ms2ger`: yep |
| 22:49 | <zcorpan> | benschwarz: cool |
| 22:52 | <zcorpan> | hmm, the html element is still the-html-element-0 |
| 22:52 | <zcorpan> | jirka's list was not complete |
| 22:53 | <zcorpan> | Hixie: can't you set an explicit id for all elements so they're guaranteed to be stable? |
| 22:54 | <Hixie> | i can, but it's a pain |
| 22:54 | <Hixie> | <html> has an explicit id now though |
| 22:54 | <Hixie> | it was in his list |
| 22:54 | <zcorpan> | oh |
| 22:56 | <zcorpan> | ah yep, maybe the redeployment of developers.whatwg.org hadn't reached me yet. or i had it cached. or something |
| 22:57 | <zcorpan> | but body is still broken |
| 22:58 | <Hixie> | you have to reload developers.whatwg.org |
| 22:58 | <Hixie> | because it has appcache |
| 22:59 | <Hixie> | fixing body |
| 23:00 | <benschwarz> | zcorpan, Hixie — https://github.com/benschwarz/developers.whatwg.org/commit/894f834a99628f82f7435639ba223a5e0b224858 |
| 23:00 | <benschwarz> | (also deployed) |
| 23:01 | <zcorpan> | Hixie: video is also broken |
| 23:01 | <Hixie> | i fixed video, didn't i? |
| 23:02 | Hixie | loosk |
| 23:02 | <zcorpan> | uh |
| 23:02 | <zcorpan> | yep video is in the diff |
| 23:02 | <Hixie> | yup |
| 23:02 | <zcorpan> | developers.whatwg.org refusing to update for me again |
| 23:02 | <Hixie> | didn't it take? |
| 23:02 | <Hixie> | zcorpan: you have to wait for your browser to update the appcache |
| 23:02 | <Hixie> | zcorpan: then reload |
| 23:03 | <zcorpan> | or wait, i wasn't even looking at developers.whatwg.org |
| 23:06 | <zcorpan> | hmm. when reloading http://developers.whatwg.org/video.html a few times i get four "whatwg" logos and four "in this section" buttons |
| 23:07 | <Hixie> | o_O |
| 23:09 | <zcorpan> | http://validator.nu/?doc=http%3A%2F%2Fdevelopers.whatwg.org%2Fvideo.html |
| 23:11 | <aho> | so... what's the replacement for hgroup? |
| 23:11 | <Hixie> | aho: <hgroup> is still in html, just not in the w3c copy of html5. |
| 23:11 | <Hixie> | the w3c copy is missing many newer things. |
| 23:11 | <aho> | *scratches head* |
| 23:11 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? |
| 23:13 | <zcorpan> | Hixie: ok seems like all links are working now |
| 23:13 | <aho> | so, it still exists and will continue to do so for the foreseeable future? |
| 23:13 | <Hixie> | zcorpan: cool |
| 23:13 | <Hixie> | aho: yeah, it's not going anywhere. even the spec uses it. |
| 23:13 | <aho> | heh |
| 23:13 | <aho> | ok |
| 23:13 | <aho> | :) |
| 23:14 | <Hixie> | (at least on the whatwg site... the w3c html spec uses html4, so it can't use hgroup or any of the new elements.) |
| 23:15 | <zcorpan> | how come http://www.w3.org/Bugs/Public/show_bug.cgi?id=11828 is NEEDSINFO? |
| 23:18 | <Hixie> | resolution was changed by nicolasgallagher⊙mc |
| 23:18 | <Hixie> | @gmail, even |
| 23:18 | <Hixie> | dunno why |
| 23:23 | <zcorpan> | also no comment about the spec checkin |
| 23:24 | <zcorpan> | oh sorry there was a comment |
| 23:24 | <Hixie> | my script is a bit bitchy when it comes to adding that comment |
| 23:25 | <Hixie> | something to do with encoding errors or something, i think |
| 23:25 | <Hixie> | it used to not commit at all if there was invalid utf-8, i think i fixed that but it's still not completely ok |
| 23:25 | <Hixie> | i haven't cared enough to investigate exactly what the problem is |
| 23:40 | <Hixie> | anyone know if the idea of doing textarea.selectionDirection="backward" ever got implemented anywhere? |
| 23:41 | <AryehGregor> | Not that I've heard of. |
| 23:41 | <Hixie> | should i just spec it or wait for impl experience? |
| 23:42 | <aho> | is specified what should happen if you click on the some input[type=text]'s label? |
| 23:43 | <Hixie> | more or less |
| 23:43 | <aho> | chrome and firefox select the text (if any), opera doesn't |
| 23:43 | <Hixie> | it should do the same as is normal on that platform |
| 23:43 | <aho> | hum |
| 23:44 | <aho> | firefox doesn't select the search text in the find bar, if i click on the "find:" label |
| 23:44 | <aho> | clicking on some textfield's label doesn't seem to do anything in windows programs |
| 23:45 | <Hixie> | (note when drawing conclusions here that it might differ for different types of controls) |
| 23:45 | <Hixie> | (e.g. windows checkbox labels are interactive) |
| 23:45 | <aho> | oh yea... what does work in all browsers is clicking a button by clicking it's associated label (which is kinda weird) |
| 23:46 | <aho> | *its |
| 23:47 | <aho> | i think opera does at least focus the text field |
| 23:48 | <aho> | http://kaioa.com/k/labelfocus.html |
| 23:49 | <aho> | well, that was my use case basically... i didn't want to add js just to select that text |
| 23:54 | <Hixie> | othermaciej: i'm adding textarea.selectionDirection; is this something i should exclude from the w3c copy? i'm confused as to what counts as a new feature and what doesn't. |
| 23:55 | <othermaciej> | Hixie: I don't know offhand what that is, but excluding it for now unless someone requests otherwise is a safe course |
| 23:56 | <Hixie> | it's an attribute added to <input> and <textarea> to control what direction the selection is in |
| 23:56 | <Hixie> | goes with selectionStart and selectionEnd |
| 23:58 | <Hixie> | othermaciej: i'm not really asking whether it's "safe", so much as what i should do |
| 23:59 | <Hixie> | othermaciej: if it helps, i request it :-) |
| 23:59 | <othermaciej> | if you leave it out, then probably no one will complain |
| 23:59 | <othermaciej> | if you think no one will complain about adding it (seems like they probably wouldn't), then it seems fine to add it |
| 23:59 | <Hixie> | k |
| 23:59 | <othermaciej> | if in doubt, you can always ask on public-html |