| 00:29 | <Hixie> | so this event.dataTransfer.items.add() method... should the "type" argument be first, or the "data" argument? |
| 00:29 | <Hixie> | DOMStringMap's setter uses the order "name, value" |
| 00:30 | <AryehGregor> | Without any context, if both arguments are mandatory, "type" then "data" makes more sense to me. Although I have no actual idea what you're talking about. |
| 00:30 | <Hixie> | this is for drag and drop |
| 00:30 | <Hixie> | the new API |
| 00:30 | <Hixie> | that lets you add new things to the drag data store |
| 00:30 | <Hixie> | in the dragstart event, you can now do event.dataTransfer.items.add('text/plain', 'my data') |
| 00:30 | <Hixie> | or event.dataTransfer.items.add(input.value, 'text/plain') |
| 00:31 | <Hixie> | i could see arguments both ways |
| 00:31 | <Hixie> | the data,type order's main argument is that type is an annotation and annotations should go second because we might add more later |
| 00:32 | <Hixie> | the type,data order's main argument is that the type is the key of the item, and APIs always give the key/name before the value |
| 00:33 | <Hixie> | data,type would argue that it's not the key because it could even be made optional (defaulting to text/plain) |
| 00:33 | <AryehGregor> | Making it optional seems like the best way to go. |
| 00:33 | <Hixie> | type,data would argue that that will almost never happen, and that in fact should not happen since we would not want apps making their internal formats text/plain, and so we should have it first so that authors have to think about it |
| 00:34 | <boogyman> | Is there a default"type"? and if so, would it be safe to say that many developers would enjoy the implicit negation of type unless necessary? |
| 00:34 | <Hixie> | data,type would argue yes, that text/plain should be the default type, because it maximises the chance of being able to drag data out. type,data would argue no, because we don't want internal data being draggable to text fields, and so you should always give a type, not rely on a default |
| 00:38 | <boogyman> | Hixie: I agree that explicitly stating a type is following proper coding technique. |
| 00:38 | <AryehGregor> | Would authors primarily use this for custom data types? |
| 00:39 | <AryehGregor> | If so, doesn't it seem kind of awkward to demand they specify a MIME type for that? Are they supposed to make one up? |
| 00:43 | <Hixie> | they're _supposed_ to register one |
| 00:43 | <Hixie> | but yeah |
| 00:47 | <AryehGregor> | Register one. |
| 00:47 | <AryehGregor> | Seriously? |
| 00:47 | <AryehGregor> | You expect web authors to register a MIME type? |
| 00:47 | <AryehGregor> | They're going to reuse whatever boilerplate they copy and paste from tutorials or other pages. |
| 00:48 | <Hixie> | i don't expect developers of million-dollar application software to register a MIME type, let alone a random web author |
| 00:48 | <boogyman> | AryehGregor: I assume he means "declare" in place of "register" |
| 00:49 | <Hixie> | no, i meant register |
| 00:49 | <AryehGregor> | So why did you say such a blatantly crazy thing as to say that authors are supposed to register a MIME type? |
| 00:49 | <Hixie> | however, the mime type problem is basically water under the bridge... unless we have an idea for how to change how drag-and-drop works, the idea here was just to expose the model with a better API |
| 00:49 | <Hixie> | not change the model |
| 00:49 | <AryehGregor> | Sad. |
| 00:49 | <AryehGregor> | Hmm. |
| 00:49 | <Hixie> | well if there's a better model i'm all for it, i just don't know what it is |
| 00:50 | <Hixie> | the reality is that mime types are how we label types on the web |
| 00:50 | <Hixie> | and here we are talking about types |
| 00:50 | <Hixie> | so... |
| 00:50 | <Hixie> | personally i think we should do away with the mime type registry and have a wiki instead |
| 00:50 | <AryehGregor> | They won't register on a wiki either. |
| 00:50 | <Hixie> | indeed |
| 00:50 | <AryehGregor> | Why is a type needed? So that different programs don't grab each other's data by mistake? |
| 00:50 | <Hixie> | so that you can have multiple types |
| 00:51 | <Hixie> | e.g. drag a table from a spreadsheet and you'll get several formats: CSV, tabbed text, plain text, HTML, the spreadsheet package's own format, rich text, etc |
| 00:51 | <Hixie> | drag it to notepad, it'll take the text |
| 00:51 | <Hixie> | drag it to Word or Pages, it'll take the rich text |
| 00:51 | <Hixie> | drag it to another sheet in the same product, it'll use the internal format |
| 00:52 | <AryehGregor> | I guess I don't have a clear grasp of all the use-cases here. |
| 00:53 | <Hixie> | i guess we could put the type second, make it optional, and default it to text/internal-drag-and-drop-format;origin=http://example.com or some such (with the origin autopopulated) |
| 00:53 | <AryehGregor> | "we don't want internal data being draggable to text fields" -- what's "internal data"? If this is being used for "internal data", then it would make more sense to be able to pass around JS data types instead of just strings. |
| 00:53 | <AryehGregor> | (which could secretly be serialized to JSON) |
| 00:53 | <Hixie> | (but that would make accepting the drop a bit of a pain... unless we make dropzone="" have some special format for this... hmm...) |
| 00:54 | <Hixie> | AryehGregor: internal data = whatever the script just added to the drag data store, e.g. in a game of some sort it could be the ID of a spaceship, or the orders for a train, or whatnot |
| 00:54 | <AryehGregor> | Then you'd really want to dump objects and arrays and things there, not just strings. |
| 00:54 | <Hixie> | yes |
| 00:54 | <Hixie> | one thing at a time though :-) |
| 00:54 | <AryehGregor> | :) |
| 00:54 | <Hixie> | right now i'm specifically looking at the method for adding text |
| 02:47 | <MikeSmith> | /msg agektmr |
| 02:47 | <MikeSmith> | hmm |
| 02:47 | <MikeSmith> | sorry |
| 03:17 | <zcorpan> | so xml-stylesheet was published http://www.w3.org/TR/2010/REC-xml-stylesheet-20101028/ |
| 03:20 | <heycam> | congrats zcorpan :) |
| 03:20 | <zcorpan> | thanks heycam |
| 03:21 | <zcorpan> | which spec should i target next? |
| 03:29 | <heycam> | zcorpan, dom xpath? |
| 03:30 | <zcorpan> | hmm |
| 03:30 | <heycam> | domparser? |
| 03:31 | <zcorpan> | domparser and xmlserializer could probably just be part of dom core |
| 03:31 | <zcorpan> | they seem pretty trivial |
| 03:31 | <heycam> | yeah, probably |
| 03:32 | zcorpan | looks at http://wiki.whatwg.org/wiki/Companion_specifications |
| 03:34 | <zcorpan> | maybe a spec to glue DOM and XML together better... XML5... though i had wanted to get out of XML land |
| 03:34 | <zcorpan> | i'm never going to convince the xml core wg to rewrite the xml spec |
| 03:38 | <othermaciej> | does the Infoset spec sufficiently define how to map the XML syntax to the Infoset? |
| 03:38 | <othermaciej> | if so, then you can reduce the problem to mapping from Infoset to DOM |
| 03:40 | <zcorpan> | that still doesn't define what happens when it's not well-formed, or when you move nodes with script, and other such things |
| 03:40 | <zcorpan> | which are well-defined for text/html |
| 03:41 | <othermaciej> | well, what happens when its not well-formed is indeed something XML punted on |
| 03:41 | <othermaciej> | or rather, they say it means hard failure, though some people retroactively interpret that as actually meaning you can do whatever you want as long as you flag an error |
| 03:41 | <zcorpan> | also, infoset doesn't say whether to load external entities |
| 03:42 | <othermaciej> | moving nodes with script during parsing is indeed an issue |
| 03:42 | <othermaciej> | and some things that are optional in XML, you pretty much have to pick one or the other when processing Web content |
| 03:43 | <zcorpan> | i'd like to address the underlying problem and do XML5... except i don't really want to work on XML |
| 04:19 | <webr3> | domparser and xmlserializer could probably just be part of dom core <-- that would be great, really need them in web workers too.. or some form of XML/DOM support |
| 04:28 | <zcorpan> | well supporting DOM in workers is a separate issue |
| 04:33 | <zcorpan> | http://ie.microsoft.com/testdrive/Graphics/MBSCustomerModel/Default.html is really slow in firefox |
| 04:51 | <tmpvar> | hey guys, quick question: has anyone developed a test suite for the BOM? specifically things like: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#window ? |
| 04:54 | <zcorpan> | you mean DOM? |
| 04:58 | <webr3> | eh, anybody know how Cameron McCormack has managed to get his name removed whenever you reply-all to him? hit reply and it replies to him, hit reply all and his names gone - that's awesome |
| 05:01 | <zcorpan> | Mail-Followup-To: Nathan <nathan⊙wo>, public-webapps <public-webapps⊙wo> |
| 05:02 | <zcorpan> | maybe? |
| 05:02 | <hober> | I miss Gnus. |
| 05:06 | <webr3> | zcorpan, looks about right - will have a (whatever word i put here sounds a bit wrong) |
| 05:06 | <webr3> | actually, tomorrow - it's way to late |
| 05:07 | <tmpvar> | zcorpan, if you call Window part of the dom then yes |
| 05:07 | <zcorpan> | tmpvar: i would, yeah |
| 05:08 | <zcorpan> | tmpvar: i'm not aware of any testsuite for window specifically |
| 05:08 | <heycam> | _o, i replied to your mail asking that |
| 05:08 | <heycam> | for others: yeah it's the Mail-Followup-To |
| 05:09 | <heycam> | but now that i have sorted out my procmailrc so that the directly-addressed mail goes to my inbox and the one delivered to the mailing list goes to the relevant folder for the list, i'm happy to receive multiple copies :) |
| 05:09 | <heycam> | bfn |
| 05:53 | <symbole> | There's some ambiguity in the WebSocket Protocol standard. Is this the correct channel to ask for a clarification? |
| 05:53 | <micheil> | symbole: probably or the hybi mailing list |
| 05:56 | <symbole> | Does the standard assume integer division? |
| 05:57 | <symbole> | Hmm, I don't think that's necessary. I think it's clearer now. |
| 05:57 | <micheil> | well, depends which version |
| 05:57 | <micheil> | it's not a standard |
| 05:57 | <micheil> | it's a draft |
| 05:57 | <micheil> | there's -75 and -76 (implemented) and -03 (latest) |
| 05:58 | <symbole> | I was referring to -76. |
| 05:58 | <micheil> | okay |
| 05:58 | <micheil> | let me check what I use.. |
| 05:59 | <micheil> | symbole: k, so, for numkey, I use integers |
| 05:59 | <micheil> | and for spaces I use integers |
| 05:59 | <symbole> | I don't think it's necessary to assume integer division, because the next steps says "integer from 0 to max_1". |
| 06:00 | <symbole> | micheil: What is this -03 version you're referring to? |
| 06:00 | <micheil> | it's the next version to be implemented |
| 06:00 | <micheil> | it has new packet format and probably new handshaking |
| 06:00 | <symbole> | Where can I find this document? |
| 06:03 | <symbole> | Perhaps I should rush to implement 76 if a new draft will repalce it. |
| 06:04 | <symbole> | not rush* |
| 06:05 | <micheil> | perhaps. |
| 06:05 | <micheil> | but at the moment, -76 is in Chrome, Chromium, Safari, Firefox and Opera |
| 06:05 | <micheil> | MSIE is missing, and I can't test for support. |
| 06:06 | <symbole> | I found 03. |
| 06:07 | <symbole> | Hmm, it's quite different. |
| 06:08 | <micheil> | it is |
| 06:09 | <micheil> | and the proposals for -04 and -05 are even more different |
| 06:09 | <symbole> | Do you happen to know if any of the browers plan to change from -76? |
| 06:11 | <micheil> | no, I don't |
| 06:11 | <micheil> | Rik`, zcorpan or Hixie may. |
| 06:11 | <micheil> | there is currently only one server implementation of -04 I know of. |
| 06:14 | <symbole> | Thanks micheil. |
| 06:22 | <zcorpan> | ian fette said chrome were updating to -03 a while back iirc |
| 06:23 | <zcorpan> | there's an -04? |
| 08:26 | <Dashiva> | http://twitter.com/davidbaron/status/29041311189 |
| 08:26 | <Dashiva> | What kind of monster laptop (or monster book) weighs that much? |
| 08:35 | <virtuelv> | Dashiva: laptop: 2-3kg, camera: 1-3 kg, book: 0.5-1kg |
| 08:36 | <virtuelv> | then there's the weight of the bag, power supply and charger |
| 09:18 | <foolip> | jgraham, does html5lib do any kind of validation? would it be possible to use it to make a validating text editor (or validator plugin, rather)? |
| 09:31 | <annevk> | foolip, in theory |
| 09:31 | <annevk> | foolip, Mark Pilgrim at one point wrote a proof of concept validator on top of it |
| 09:34 | <foolip> | hmm, ok |
| 09:34 | <foolip> | I want emacs to validate my html for me :) |
| 09:34 | <hsivonen> | foolip: hober is working on that |
| 09:35 | <hendry> | foolip: you can do that with vim http://wiki.whatwg.org/wiki/IDE :-) |
| 09:35 | <hsivonen> | foolip: in the mean time, NetBeans tip of the tree may be of interest |
| 09:39 | <annevk> | zcorpan, if you read logs, parsing and serializing is not going in DOM Core I think as it'll create dependencies on HTML5 which I'd like to avoid |
| 09:40 | <jgraham> | foolip: The shorter answer would be "no" |
| 09:41 | <jgraham> | We hg removed the validation bits |
| 09:42 | <jgraham> | hober is working on an elisp tokenizer at least. I don't know if he will do enough to get anything like validation |
| 09:43 | <foolip> | it'd be cool if emacs wasn't written in elisp :) |
| 09:43 | <foolip> | what's vims internal scripting language? |
| 09:43 | <hsivonen> | foolip: hey! lisp has no bugs! |
| 09:43 | <jgraham> | is it the "e" part you object to or the "lisp" part? |
| 09:44 | <hsivonen> | jgraham: does the "e" part introduce bugs? |
| 09:44 | <foolip> | the lisp part. I don't mind functional, but I do mind the syntax |
| 09:44 | <jgraham> | hsivonen: I am not an expert, but I don't think elisp is a highly regarded lisp dialect |
| 09:45 | <jgraham> | foolip: So you want a text editor that is scripted in haskell, right? :) |
| 09:45 | <foolip> | hehe, no, python :) |
| 09:45 | <foolip> | http://en.wikipedia.org/wiki/Vim_script |
| 09:45 | <foolip> | looks like vim won't make me happy either |
| 09:45 | <foolip> | aaah: " but plugins can also utilize other scripting languages like Perl or Python (if support for them is compiled into the Vim binary)." |
| 09:46 | <foolip> | anyway, back to "work" |
| 09:46 | <jgraham> | I think you *can* script (parts of) emacs in python |
| 09:46 | <jgraham> | But I am not sure |
| 09:51 | <annevk> | zcorpan, if you are still reading, how about finally writing that CSS Quirks Module :) |
| 10:09 | <zcorpan> | annevk: ok (re dom core) |
| 10:09 | <zcorpan> | bummer |
| 10:09 | <zcorpan> | annevk: cool (re quirks) |
| 10:10 | <annevk> | :) |
| 10:10 | <annevk> | for parsing and serializing I was thinking a separate spec |
| 10:10 | <annevk> | that also generalizes innerHTML |
| 10:10 | <annevk> | and does DOMParser and XMLSerializer |
| 10:11 | <annevk> | and maybe the mapping of XML -> DOM |
| 10:12 | <zcorpan> | do you have the quirks spec up somewhere? |
| 10:12 | <annevk> | apart from dbaron's Mozilla documents and source code I do not think there is anything |
| 10:13 | <annevk> | well, HTML5 now defines the hooks :) |
| 10:13 | <zcorpan> | oh, i thought you had started to put down some words |
| 10:14 | <zcorpan> | uh |
| 10:14 | <zcorpan> | i totally misread what you wrote first |
| 10:15 | <zcorpan> | so yeah, that could be a fun spec to do |
| 11:13 | <jgraham> | <table><caption><math></table><p> |
| 11:14 | <jgraham> | Seems to have the <p> as a child of the <caption> in the latest spec whereas before it was a child of the <table> |
| 11:14 | <jgraham> | Anyone recall off hand if that change was intentional? |
| 11:14 | <jgraham> | hsivonen: ^ |
| 11:15 | <jgraham> | erm, not <table> |
| 11:15 | <jgraham> | <body> |
| 11:15 | <jgraham> | obviously |
| 11:25 | <hsivonen> | jgraham: no idea if it was intentional |
| 11:25 | <hsivonen> | jgraham: I very much suspect it wasn't intentional |
| 11:26 | <hsivonen> | frankly, I'm starting to lose my patience with having "in foreign content" as a mode |
| 11:27 | <hsivonen> | instead of doing what I suggested in http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659#c20 and onwards |
| 11:27 | <zcorpan> | why would </body> close the caption? |
| 11:27 | <zcorpan> | seems like a bug fix to me |
| 11:27 | <hsivonen> | zcorpan: jgraham had </table> there |
| 11:28 | <zcorpan> | ah |
| 11:32 | <jgraham> | It is of course possible that I am misreading the current spec |
| 11:33 | <jgraham> | But I think one ends up processing </table> In Body where it is ignored |
| 11:34 | hsivonen | wonders where the media accessibility requirements that look like copied and pasted from elsewhere were copied and pasted from |
| 11:34 | <hsivonen> | pasted the suspicious reqs to Google doesn't yield exact hits revealing the source |
| 11:36 | <hsivonen> | s/ed/ing/ |
| 11:38 | <jgraham> | hsivonen: The unicode requirement at least seems to be the same version as referenced in UAAG 2.0 |
| 11:40 | <hsivonen> | jgraham: ok |
| 11:41 | <abarth> | hsivonen: branches per token aren't measurable, AFACT |
| 11:42 | <abarth> | branches per character, however, are :) |
| 11:43 | <jgraham> | abarth: Context? |
| 11:43 | <hsivonen> | abarth: AFAICT, what I suggested wouldn't require implementations to introduce new per-char branches |
| 11:43 | <abarth|decoders> | jgraham: hsivonen's comment about changing foreign content not to be a mode |
| 11:43 | <jgraham> | Oh hsivonen's suggestion |
| 11:43 | <jgraham> | I assume that would be per-token |
| 11:45 | <hsivonen> | I wonder if I could talk sicking into approving the implementation of my suggestion in Gecko. Then disagreements between Gecko and the spec could summarily be treated as spec bugs |
| 11:45 | <abarth|decoders> | that doesn |
| 11:45 | <abarth|decoders> | t seem in the spirit of this process |
| 11:46 | <hsivonen> | abarth|decoders: didn't Hixie say what effectively amounted to everything where my suggestion and the spec a distinguishable being spec bugs? |
| 11:46 | <jgraham> | I am slightly concerned that we are either going to end up with non-interoperable foreign content handling, or buggy-at-the-spec-level foreign content handling or both |
| 11:46 | <hsivonen> | s/a/are/ |
| 11:47 | <jgraham> | (that's in roughly reverse order of probability) |
| 11:47 | <hsivonen> | jgraham: I think the easiest way to avoid buggy-at-the-spec-level would be not prematurely optimizing on the spec level |
| 11:47 | <abarth|decoders> | it's important that we stop changing the spec at some point |
| 11:48 | <abarth|decoders> | otherwise, we're going to end up with a mess |
| 11:48 | <jgraham> | abarth|decoders: Agreed. But we are already heading that way |
| 11:49 | <hsivonen> | abarth|decoders: indeed. which is why I'm so frustrated with more and more "in foreign content" bugs showing up and being traceable to a premature optimization on the spec level |
| 11:50 | <abarth|decoders> | i suspect webkit won't change much in the parser for a while |
| 11:50 | <abarth|decoders> | and wait for the spec to stop changing |
| 11:50 | <hsivonen> | abarth|decoders: on the bright side, the current differences between Gecko trunk and WebKit trunk are much less of a mess than the delta before HTML5 |
| 11:50 | <abarth|decoders> | then we'll do a sweep and fix whatever needs to be changed |
| 11:50 | <abarth|decoders> | oh, yes, indeed :) |
| 11:50 | <abarth|decoders> | the possibility of getting it exactly right are tantalizing :) |
| 11:50 | <jgraham> | Indeed. It is all a win for sure |
| 11:51 | <jgraham> | But it will be sad to birth a new feature (mixed content text/html) with bad interop or weird behaviour |
| 11:52 | <abarth|decoders> | that's true |
| 11:52 | <abarth|decoders> | however, i'm a big believe in worse-is-better |
| 11:52 | <abarth|decoders> | :) |
| 11:52 | <jgraham> | Although maybe Microsoft have consigned us to that path anyway; I haven't tried SVG-in-HTML in IE9 |
| 11:52 | <hsivonen> | jgraham: I haven't tried the latest PP, but the earlier stuff wasn't compliant to any spec draft |
| 11:53 | <jgraham> | Right, my impression was they had taken an approach that could be broadly described as "making shit up" |
| 11:53 | <abarth|decoders> | i suspect that will just lead them down a path of pain |
| 11:54 | <zcorpan> | iirc they initially didn't implement the breakout at all, but i filed a bug about it and in a later PP they did implement the breakout |
| 11:54 | <zcorpan> | i didn't check carefully how well it matched the spec |
| 11:55 | <hsivonen> | zcorpan: I didn't test even that profoundly. My testing result was that the case correction and xlink:href stuff was wrong |
| 11:55 | <zcorpan> | i infer from the latest demos that the latest PP supports <article> etc, btw |
| 11:57 | <hsivonen> | abarth|decoders: what's your take on "reset the insertion mode" vs. storing the insertion mode on the tree builder stack such that popping automatically restores the right mode? |
| 11:57 | <hsivonen> | abarth|decoders: that's another case where the spec contains an optimization that has been faulty in the past |
| 11:57 | <abarth|decoders> | hsivonen: honestly, i haven't looked into it |
| 11:58 | <abarth|decoders> | at the moment, I'm more interested in \n in the value attribute of the input tag |
| 11:58 | <abarth|decoders> | somehow it magically disappears in Firefox |
| 11:59 | <hsivonen> | on the bright side, the old WebKit tree builder tried to optimize the tracking of <p> on stack, but Hixie didn't try to put that optimization in the spec |
| 11:59 | <abarth|decoders> | that's causing a (minor) compat problem |
| 11:59 | <hsivonen> | abarth|decoders: sounds like volkmar's area and not a parser thing |
| 11:59 | <abarth|decoders> | the worst recent fallout from the HTML5 parser is that we broke composing email in zimbra |
| 11:59 | <abarth|decoders> | hsivonen: it regressed with the parser change |
| 12:00 | <abarth|decoders> | hsivonen: i think the parser was doing some work that should have been done elsewhere |
| 12:00 | <hsivonen> | abarth|decoders: interesting. Zimbra WFM in Gecko. |
| 12:00 | <abarth|decoders> | yeah, it's a UA detect thing |
| 12:00 | <hsivonen> | abarth|decoders: UA sniffing is sadness |
| 12:00 | <hsivonen> | (vendor prefixes are, too) |
| 12:00 | <abarth|decoders> | for the site to work, they need to call document.open to cancel a load (don't ask) |
| 12:01 | <abarth|decoders> | but they'll only do it for Safari if document.body is null |
| 12:01 | <abarth|decoders> | which is basically impossible now |
| 12:01 | <abarth|decoders> | but somehow was possible in the old parser |
| 12:01 | <hsivonen> | abarth|decoders: sounds like a really weird set of assumptions |
| 12:01 | <hsivonen> | Web apps <3 |
| 12:01 | <abarth|decoders> | yeah, their code is crap |
| 12:01 | <abarth|decoders> | they've "fixed" it |
| 12:01 | <abarth|decoders> | by adding a 30ms timeout |
| 12:01 | <abarth|decoders> | which doesn't make any sense |
| 12:01 | hsivonen | facepalms |
| 12:02 | <abarth|decoders> | it's complicated, but as long as the network load finished before the timeout |
| 12:02 | <abarth|decoders> | the site works |
| 12:02 | <abarth|decoders> | but, of course, that's not deterministic |
| 12:03 | <jgraham> | Hahaha |
| 12:03 | <zcorpan> | http://www.kingofforwards.com/wp-content/uploads/2010/01/image0103.jpg |
| 12:03 | <volkmar> | abarth|decoders: what about \n in input ? |
| 12:03 | <abarth|decoders> | i have no idea why they think Safari needs a 30 ms timeout but Firefox doesn't |
| 12:03 | <abarth|decoders> | they just need to remove the UA detect |
| 12:03 | <abarth|decoders> | the funniest part |
| 12:04 | <abarth|decoders> | is that if you don't match any of their UAs, then there's no way for the site to work |
| 12:04 | <abarth|decoders> | since they never call document.open |
| 12:04 | <abarth|decoders> | :( |
| 12:04 | <abarth|decoders> | volkmar: consider the following HTML: |
| 12:04 | <zcorpan> | do they sniff for Opera? |
| 12:04 | <Rik`> | abarth|decoders: sorry, lunch time, give us volkmar back ! |
| 12:04 | <abarth|decoders> | <input type="text" value=" |
| 12:04 | <abarth|decoders> | "> |
| 12:04 | <jgraham> | zcorpan: I think the site works in Opera |
| 12:05 | <abarth|decoders> | where there's a \r between the " and the " |
| 12:05 | <volkmar> | abarth|decoders: before it was showing " " as a value and now "", right? |
| 12:05 | <abarth|decoders> | webkit used to have "" but now has " " |
| 12:05 | <abarth|decoders> | firefox has "" |
| 12:05 | <abarth|decoders> | zcorpan: yes |
| 12:06 | <volkmar> | abarth|decoders: but that's what the specs want, AFAICT |
| 12:06 | <abarth|decoders> | zcorpan: the IE code path is even more insane than the others |
| 12:06 | <abarth|decoders> | volkmar: which? |
| 12:06 | <hsivonen> | Zimbra doesn't run if it finds "Gecko/" in the UA string without the next character being a digit... |
| 12:07 | <volkmar> | abarth|decoders: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#text-state-and-search-state |
| 12:07 | <volkmar> | see "The value sanitization algorithm is as follows: Strip line breaks from the value." |
| 12:08 | <abarth|decoders> | volkmar: thanks. webkit must be missing that requirement |
| 12:08 | <volkmar> | i guess |
| 12:11 | <abarth|decoders> | ok, bed time for me |
| 12:11 | <zcorpan> | nn |
| 12:28 | <jgraham> | OK, I think that with <svg><foreignObject><div><frameset> and the same with s/frameset/select/ you can now reset the insertion mode into "In Frameset" and "In Select" which previosuly was only possible with innerHTML |
| 12:37 | <hsivonen> | jgraham: looks like we really should get rid of "in foreign content" as a mode and put the mode on the stack instead of resetting it |
| 12:39 | <jgraham> | Hmm, I managed to file the same bug twice |
| 12:41 | <annevk> | jgraham, are you sure you are not just getting two emails? |
| 12:41 | <jgraham> | Different bug number |
| 12:41 | <jgraham> | Resolved as dupe, anyway |
| 12:41 | <annevk> | aah, sucks |
| 12:43 | <annevk> | lol |
| 12:43 | <annevk> | http://www.brucelawson.co.uk/2010/five-things-carrots-can-do-that-html5-cant/ |
| 12:52 | <zcorpan> | the carrot looks like a penis |
| 12:54 | <zcorpan> | i don't know if that's a win or a fail for the carrot |
| 13:05 | <Rich_Clark> | Question re @formaction etc, why are they required in HTML5? What's the difference between that & @action on a form? |
| 13:05 | <annevk> | zcorpan, guess he couldn't make that joke in front of his kids |
| 13:12 | <zcorpan> | Rich_Clark: you may want to use different actions for different submit buttons |
| 13:13 | <Rich_Clark> | zcropan: rather than splitting into individual forms? |
| 13:14 | <annevk> | right |
| 13:14 | <Rich_Clark> | zcorpan: also I assume the same reasoning is valid for @formenctype, @formmethod, @formtarget & @form? |
| 13:14 | <annevk> | and formnovalidate |
| 13:14 | <zcorpan> | form="" is different |
| 13:15 | <annevk> | right, not form |
| 13:15 | <Rich_Clark> | ah yeah, associates an input with a form, right |
| 13:16 | <Rich_Clark> | so use case would be something like a .NET template that wraps the whole document in a form? |
| 13:16 | <zcorpan> | the use case for formnovalidate="" is "save draft" button where the form has required fields but you don't need to fill them out for saving, only for publishing |
| 13:18 | <annevk> | Rich_Clark, the use case for form="" is tables |
| 13:20 | <Rich_Clark> | annevk: right, thanks. Makes sense. |
| 13:21 | <Rich_Clark> | zcorpan: so that's why you'd use @formnovalidate over @novalidate? |
| 13:22 | <zcorpan> | yeah |
| 13:22 | <zcorpan> | use novalidate="" if you don't want to validate the form but still benefit from nice UI with type=url or so |
| 13:23 | <zcorpan> | i don't know what the use cases are for formenctype, formmethod or formtarget |
| 13:24 | <zcorpan> | well i could imagine formtarget for preview in iframe |
| 13:26 | <Rich_Clark> | great, thanks |
| 13:27 | <annevk> | i think it was mostly completeness |
| 13:27 | <annevk> | maybe so the <form> can be in the template, but you do not need the attributes of <form> to be changeable |
| 13:28 | <annevk> | quite the edge case scenario though |
| 14:13 | <karlcow> | http://paramsr.us/tracker/ |
| 14:14 | <karlcow> | experimental rel values tracker |
| 14:14 | <karlcow> | announced at http://lists.w3.org/Archives/Public/public-html/2010Oct/0460 |
| 14:28 | <hsivonen> | karlcow: I guess a domain owned by mnot is much better than a domain owned by Hixie... |
| 14:28 | <karlcow> | no better. |
| 14:34 | <jsumners> | where can i read about why the 'name' attribute on the 'a' element is obsolete? |
| 14:35 | <Philip`> | (Seems to be based on http://pypi.python.org/pypi/roundup) |
| 14:35 | <Philip`> | jsumners: http://www.w3.org/TR/xhtml1/#h-4.10 |
| 14:35 | <hsivonen> | jsumners: around the HTML 4 timeframe, some people thought id was much superior and since Netscape 4 died, everyone implements id, so the transition is relatively complete |
| 14:36 | <hsivonen> | jsumners: in retrospect, the transition seems rather pointless |
| 14:37 | <jsumners> | okay, that clears it up. thank you |
| 14:40 | karlcow | wonders if bruce's site is down. Slashdotted or something? |
| 14:41 | karlcow | sees it is working now |
| 14:43 | mpilgrim | idly wonders if web sockets work interoperably yet |
| 14:44 | <jgraham> | mpilgrim: "sort of" |
| 14:44 | <mpilgrim> | what's the best wrapper? socket.io? |
| 14:45 | <jgraham> | Opera+Firefox+WebKit have -00 support in their latest dev releases (stable inthe case of Chrome/Safari) |
| 14:45 | Philip` | thought the problem was that everyone now interoperably implements an insecure protocol |
| 14:45 | <hsivonen> | mpilgrim: the question isn't "yet" but "for how long" |
| 14:45 | <jgraham> | The latest IETF draft is incompatible with -00 |
| 14:46 | <jgraham> | Chrome are talking about implementing the latest draft |
| 14:46 | <jgraham> | A future draft will likely be incompatible with the current draft |
| 14:46 | <mpilgrim> | i'll take that as a "no", then |
| 14:47 | <jgraham> | Oh and the conversation on the mailing list died |
| 14:47 | <jgraham> | Without reaching any agreement |
| 14:47 | <mpilgrim> | that's utterly shocking |
| 14:49 | <mpilgrim> | holy crap, socket.io supports ie 5.5 |
| 14:49 | <mpilgrim> | that's... disturbing |
| 14:49 | <jgraham> | WHATWG haters never mention the fact that Hixie has a great record of actually shipping. Other groups, not so much. |
| 14:50 | <Philip`> | mpilgrim: Why? |
| 14:51 | <Philip`> | (Is it disturbing that it's technologically possible, or that they bothered to write code that works in it, or that they bothered even testing it?) |
| 14:51 | <mpilgrim> | the latter two, mostly |
| 14:52 | <mpilgrim> | i don't even know where i would get a copy of ie 5.5 |
| 14:52 | <Philip`> | IEs4Linux has it |
| 14:52 | <Lachy> | mpilgrim, from here http://browsers.evolt.org/?ie/win32/5.5 |
| 14:52 | <Philip`> | http://browsers.evolt.org/ has it too |
| 14:53 | <Philip`> | Hmph |
| 14:54 | <mpilgrim> | wow, that's a lot of browsers i've never heard of |
| 14:54 | <mpilgrim> | and a lot more i haven't heard about in 10 years |
| 14:54 | <mpilgrim> | whatever happened to iCab? i used to use iCab exclusively |
| 14:54 | <mpilgrim> | around the time IE5/Mac came out, IIRC |
| 14:55 | <Lachy> | iCab is still around. Last I heard, they switched to using webkit |
| 14:55 | <jgraham> | You're not an avid GrassHopper MDI Explorer fanboi then? |
| 14:55 | <jgraham> | (seems to just be an IE shell) |
| 14:56 | <mpilgrim> | wow, iCab now has an iPhone version too |
| 14:56 | <jgraham> | I was going to say "wow iCab charges money" |
| 14:59 | <karlcow> | "Our attention is now focused on delivering the W3C satellite in mid-2011 and on initiating a new programme to compensate for this loss." |
| 14:59 | <karlcow> | -- http://www.physorg.com/news/2010-10-eutelsat-just-launched-television-satellite.html |
| 15:00 | <jgraham> | They finally decided to put MikeSmith into orbit? |
| 15:01 | <karlcow> | s/Ariane 5/MikeSmith 5/ |
| 16:12 | <MikeSmith> | hober: http://github.com/nyuhuhuu/htmllib-elisp |
| 16:15 | <jgraham> | MikeSmith: All the files are empty |
| 16:17 | <MikeSmith> | jhmm |
| 16:18 | jgraham | wonders if it is too much to ask for emacs to have working copy and paste |
| 16:20 | <Philip`> | I expect it works fine, as long as you use Emacs as your entire desktop environment |
| 16:22 | Philip` | uses the 'mswin' script for vim, and then things like clipboard access seem to work fine and with the standard keys |
| 16:24 | <AryehGregor> | The standard way to access your clipboard in vim is "+, right? Like "+y and "+p and "+P and, I don't know, whatever else you can do with clipboards? |
| 16:24 | <AryehGregor> | It seems to work with vim locally, but alas, not on remote servers. Then I just need to rely on xterm pasting it and hope vim doesn't autoindent it too badly (or briefly use :set paste). |
| 16:25 | <jgraham> | It's not the keys that are the problem, it is the weirdness around which clipboard the text ends up on. Mostly now I copy from emacs, paste into gedit, copy from gedit and paste to the final destination |
| 16:25 | <AryehGregor> | . . . it's scary how many features even vim has. I don't want to know about emacs. |
| 16:25 | <jgraham> | Which is about as awful a solution as it sounds |
| 16:26 | AryehGregor | occasionally re-reads parts of the vim manual to learn about all the crazy awesome features he's never heard of. |
| 16:26 | <AryehGregor> | I should commit to memorizing one more navigation command per week and actually using it when appropriate, that way I'll actually learn them all. |
| 16:26 | <karlcow> | jgraham: http://www.emacswiki.org/emacs/CopyAndPaste would that help? |
| 16:30 | <jgraham> | karlcow: Who knows. Maybe. I guess I can try throwing elisp I don't understand at the problem. |
| 16:30 | <jgraham> | Thanks for the pointer |
| 16:48 | <hsivonen> | jgraham: Canonical's support suggested buying a separate server for running gcc! |
| 16:50 | <jgraham> | Oh, that is quite awesome |
| 16:58 | jgraham | wonders if people complaining that the iPhone couldn't run multiple applications were told to buy more iPhones |
| 17:01 | <Philip`> | Seems like a more helpful response than "sorry, there's nothing you can do at all" |
| 17:01 | <Philip`> | (though less helpful than an actual fix) |
| 17:38 | <hober> | foolip jgraham: yeah, I intend the elisp tokenizer to be the backend for (yet another) html major mode |
| 17:38 | <hober> | I'm hoping to get a lot of value out of it in terms of intelligent editing commands without having to implement the treebuilder |
| 17:38 | <hober> | (which I'm sure I'll do anyway at some point, admittedly) |
| 17:41 | <hsivonen> | I wonder what kind of problems actually get solved by support |
| 17:41 | <hsivonen> | I've had one of my issues semi-solved until the next major Ubuntu release broke stuff so that even the workaround no longer worked |
| 17:43 | <hober> | MikeSmith: interesting. I'll ping him and point out I've already got the tokenizer implemented http://github.com/hober/html5-el/blob/master/html5-tok.el |
| 17:43 | <hsivonen> | after reading about support contract-based open source business models, my expectation were very naive |
| 17:44 | <hsivonen> | hober: is your designed to be able to use the nxml-mode validation bits? |
| 17:46 | <hober> | well, if you want to use nxml-mode's validation bits, write xhtml5 in nxml-mode. |
| 17:47 | <hober> | if you want to use nxml-mode's relax-ng stuff in a major mode other than nxml-mode, I bet that would take a hell of a lot of effort |
| 17:47 | <hsivonen> | I take that as a "no" |
| 17:47 | <hober> | that said, the api of html5-tok.el is designed to be similar to xmltok.el, which is what nxml-mode is built on |
| 17:48 | <hober> | but you couldn't just drop it in as a replacement, since nxml-mode makes all sorts of xml assumptions that wouldn't hold |
| 17:50 | <hober> | I haven't looked yet to see how much the rng-*.el files depend on nxml-mode |
| 17:51 | <MikeSmith> | hober: I'm in Budapest for a few days and spoke at an event yesterday. I talked with this guy face-to-face there, but he didn't mention he was working on an HTML5 parser. If I'd known I would have talked to him about it more. |
| 17:51 | <hober> | if they can play nice with other major modes, I might be able to use them too. |
| 17:51 | <hober> | MikeSmith: I've interacted with him a bit before, in IRC and email. I didn't know he was working on one either. |
| 17:51 | <MikeSmith> | ah, OK |
| 17:52 | <MikeSmith> | seems like a sharp dude |
| 17:59 | <hober> | yeah, I added him to planet emacsen a while ago |
| 19:56 | <zcorpan> | so how is it again, are RECs allowed to reference non-RECs by Process? |
| 19:57 | <zcorpan> | or was it just pubrules? and you only have to make it clear to the director? or other? |
| 19:58 | <AryehGregor> | Sometimes I wish Linux were less exciting. |
| 19:58 | <Hixie> | zcorpan: just reference what needs referencing |
| 19:58 | <AryehGregor> | So that, like, I didn't have to spend two and a half hours debugging two separate kernel crashes that happen when I reboot, which have no error messages. |
| 19:59 | <AryehGregor> | (they went away when I switched to upstream kernel instead of Ubuntu's version, maybe that says something . . .) |
| 19:59 | <zcorpan> | Hixie: well i published a REC and now get questions if its references are OK according to Process |
| 19:59 | <zcorpan> | the only thing i can find about references is "Once W3C has published a Rescinded Recommendation, future W3C technical reports MUST NOT include normative references to that technical report." |
| 20:00 | <zcorpan> | in http://www.w3.org/2005/10/Process-20051014/process.html |
| 20:00 | <Hixie> | personally i recommend letting people who care about it worry about it |
| 20:00 | <Hixie> | and not worrying about it yourself :-) |
| 20:17 | <Hixie> | http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html is pretty right-on |
| 20:18 | <david_carlisle> | zcorpan: non-normatove references are OK but not normative ones, eg mathmlforcss is blocked on css 2.1 |
| 20:18 | <david_carlisle> | see box they inserted at the top of |
| 20:19 | <david_carlisle> | http://www.w3.org/TR/mathml-for-css/ |
| 20:20 | <zcorpan> | david_carlisle: i can't find anything in the Process document other than what i quoted above about references |
| 20:31 | <david_carlisle> | zcorpan: quite:) but they blocked us anyway, they also wanted to block mathml3 but we persuaded them that the css reference wasn't really normative and allowed us to move the reference to the non normative reference appendix |
| 20:34 | <Hixie> | god forbid we make progress! |
| 20:53 | <annevk> | Selectors also got blocked |
| 20:54 | <annevk> | It is basically up to the Director whether or not your draft gets through |
| 20:55 | hsivonen | looks forward to reading "W3C says it's too early to deploy Selectors" in the news |
| 20:56 | <Hixie> | annevk: yet more reason to forget about the TR/ page :-) |
| 20:56 | <annevk> | Selectors is in PR and the only reason it did not go through is because CSS 2.1 is not through (CR at the moment) |
| 20:57 | <annevk> | Hixie, well, it is one of the reasons for working with the W3C... |
| 20:57 | <Hixie> | lol Selectors is stuck in PR until CSS2.1 is in PR? |
| 20:58 | <Hixie> | that's awesome |
| 20:58 | <Hixie> | the w3c process is so broken |
| 20:58 | <hsivonen> | why does CSS3 Foo depend on CSS 2.1 Process-wise? |
| 20:59 | <Hixie> | Selectors isn't CSS3 anything |
| 20:59 | <Hixie> | but in practice, CSS3 drafts depend on CSS2.1 for the bits that CSS3 hasn't yet defined |
| 20:59 | <Hixie> | e.g. the core grammar |
| 20:59 | <Hixie> | bbiab lunch |
| 21:00 | <annevk> | usually it depends on CSS 2.1 because the CSS "3" equivalent is less mature |
| 21:02 | <annevk> | one major thing Selectors leaves to CSS 2.1 is the definition of ::before and ::after |
| 21:25 | <zcorpan> | ah, so apparently readonly in webidl is tied to es5 strict mode... |
| 21:36 | <slinkcoding> | hi |
| 21:36 | <zcorpan> | hi |
| 22:05 | <AryehGregor> | "XML/HTML convergence, by Tim Berners-Lee (W3C)" |
| 22:05 | <AryehGregor> | That should be interesting. |
| 22:06 | <Philip`> | By "interesting" do you mean "another attempt to get the colon namespace syntax into HTML"? |
| 22:06 | Philip` | doesn't know if people have given up on that idea yet |
| 22:07 | <Dashiva> | You don't need to know, the answer is axiomatically no |
| 22:07 | <AryehGregor> | Are you implying that a desire to get the colon namespace syntax into HTML is a fundamental law of physics? |
| 22:08 | <AryehGregor> | Presumably that would have considerable implications for the question of intelligent design. |
| 22:08 | <Dashiva> | http://dashiva.net/test/shortbgcolor.html |
| 22:09 | <Dashiva> | All non-webkit browsers seem to fail this (parse #xyz as #0x0y0z) |
| 22:11 | <karlcow> | zcorpan: not part of the process document |
| 22:12 | <karlcow> | cf normative references |
| 22:16 | <karlcow> | there is a should in the Manual of Style but that is not mandatory. http://www.w3.org/2001/06/manual/#normative |
| 22:16 | <karlcow> | basically it is more a rule of thumb if I remember. The rationale is more on the side of if the prose is *normative by reference*, the reference as to be in a stable shape so that you do not end up with something which doesn't make sense any more if it has been completely changed. |
| 22:17 | <karlcow> | Many things are negotiable if justified. :) There are usually no dragons. ;) |
| 22:17 | <annevk> | CSS 2.1 is a dragon then |
| 22:18 | <zcorpan> | "All Recommendations have errors in them." - http://www.w3.org/2001/06/manual/#Errata |
| 22:19 | <karlcow> | annevk: this I can believe ;) |
| 22:19 | <annevk> | zcorpan, sounds like browsers |
| 22:19 | <zcorpan> | karlcow: thanks for the link |
| 22:19 | <karlcow> | QA framework was also explaining the rationale of that http://www.w3.org/TR/qaframe-spec/#ref-define-practice |
| 22:19 | <GPHemsley> | How come <a href="./page.html">Page</a> is invalid? |
| 22:20 | <GPHemsley> | (i.e. dot-initial href) |
| 22:20 | <karlcow> | it's only a *good practice*, again nothing mandatory |
| 22:20 | <zcorpan> | GPHemsley: how come you think it's invalid? |
| 22:49 | <MikeSmith> | hmm… I notice weird artifacts in the W3C bugzilla home page |
| 22:49 | <MikeSmith> | in the hypertext for "Search existing bug reports" and "Open a new Bugzilla account" |
| 22:49 | MikeSmith | looks further |
| 22:50 | <MikeSmith> | http://www.w3.org/Bugs/Public/skins/standard/index/search.gif |
| 22:52 | <MikeSmith> | looks like it's trying to put that button as a background image behind the li for the "Search existing bug reports" text |
| 22:53 | <MikeSmith> | #query { background: url(index/search.gif) no-repeat; } |
| 22:53 | <karlcow> | annevk: is Chaals still the Opera AC Rep? |
| 22:54 | <MikeSmith> | karlcow: yeah |
| 22:54 | <karlcow> | MikeSmith: thanks |
| 22:55 | karlcow | will have to read how to change affiliation again for groups (for Monday) |
| 22:55 | <Hixie> | DataTransferItem is now specced |
| 22:55 | <Hixie> | finally i can get to dropzone=""! |
| 22:57 | <MikeSmith> | Hixie: おめでとう |
| 22:57 | <MikeSmith> | or rather, gratulálok |
| 22:58 | <Hixie> | thanks |
| 22:58 | <Dashiva> | I have a dream, that one day MikeSmith will start speaking English |
| 22:58 | <Hixie> | Dashiva: translate.google.com |
| 22:58 | MikeSmith | wonders when drag and drop was first implemented |
| 22:59 | <Dashiva> | Oh, it's not that I don't understand, it's more of a comment on his polyglottitude |
| 22:59 | <Hixie> | ok so now that we have a model to talk about, the dropzone="" syntax discussion is more interesting |
| 23:00 | <Dashiva> | MikeSmith: How would you say "in meatspace" or "offline" or "in real life" in Japanese? |
| 23:00 | <MikeSmith> | Dashiva: cadw breuddwydio |
| 23:00 | <Hixie> | welsh now eh |
| 23:01 | <Dashiva> | MikeSmith: Come on, "cadw" is so obvious |
| 23:01 | <MikeSmith> | Welsh is so cool |
| 23:01 | <MikeSmith> | people who get to speak Welsh every day are lucky |
| 23:01 | <MikeSmith> | Icelandic too |
| 23:01 | <MikeSmith> | Dashiva: dunno |
| 23:02 | <MikeSmith> | offline is just katakanized |
| 23:02 | <MikeSmith> | katakana-ized |
| 23:02 | <MikeSmith> | obvious? |
| 23:02 | <Hixie> | i love that google translate can translate into latin now |
| 23:02 | <Hixie> | that's precious |
| 23:03 | <MikeSmith> | yeah, the Latin thing is fun |
| 23:03 | <MikeSmith> | I sweat it is used to do Esperanto as well |
| 23:03 | <Dashiva> | MikeSmith: What other language would use cadw |
| 23:03 | <MikeSmith> | *swear |
| 23:03 | <MikeSmith> | I don't even have any idea how to pronounce "cadw" |
| 23:04 | <Hixie> | i pronounce it "keep" |
| 23:05 | <Dashiva> | Google translate doesn't quite manage the classic "catapultam habeo. nisi pecuniam omnem mihi dabis ad caput tuum saxum immane mittam." |
| 23:05 | <Hixie> | hm |
| 23:05 | <Hixie> | what to expose to dropzone="" |
| 23:06 | <Hixie> | i guess first i should add a warning about type strings containing spaces |
| 23:08 | <MikeSmith> | Dashiva: about your question, I guess オンラインじゃない生活 or オンラインじゃない世界 |
| 23:08 | <MikeSmith> | neither of which is terrifically poetic |
| 23:09 | <Lachy> | Hixie, what's dropzone? |
| 23:09 | <MikeSmith> | but that's the way I'd say it if I was actually trying to express it myself to somebody |
| 23:09 | <Hixie> | lachy: the attribute we're adding to make it possible to declaratively do the ondragenter/ondragover part of the DND model |
| 23:09 | <Hixie> | Lachy: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10712 |
| 23:10 | <MikeSmith> | Hixie: drag and drop originally came from IE, right? Do you know how soon after it was that other browsers started to implement it? I mean, how long ago? 2005? |
| 23:11 | <Hixie> | no idea |
| 23:11 | <Hixie> | webkit was first |
| 23:11 | <Hixie> | maybe 2005? |
| 23:11 | <MikeSmith> | OK |
| 23:11 | <Hixie> | IE had it in IE4 or so |
| 23:11 | <Hixie> | years ago |
| 23:11 | <MikeSmith> | yeah, 2005 is what I was guessing for other browsers |
| 23:12 | <MikeSmith> | 5 year lag between it being implemented across multiple browsers and it actually getting spec'ed |
| 23:12 | <Hixie> | well i first specced it in like 2006 or 2007 or so |
| 23:12 | <zcorpan> | i thought firefox implemented it after Hixie specced it |
| 23:12 | <Hixie> | the new stuff i added recently isn't implemented anywhere |
| 23:13 | <Hixie> | zcorpan: yeah, iirc that's right |
| 23:13 | <MikeSmith> | oh |
| 23:13 | <MikeSmith> | OK |
| 23:13 | <Hixie> | in fact the new stuff was based on implementation feedback |
| 23:13 | <zcorpan> | opera doesn't support dnd yet |
| 23:13 | <Hixie> | it's almost directly copied from something i think the chrome team first suggested in the whatwg list, which then had some feedback from various others |
| 23:14 | <Hixie> | a few years back |
| 23:15 | <Hixie> | oh i should make dropzone="" also let you say if it's a move, copy, or link |
| 23:16 | <Hixie> | dropzone="copy text/plain text/html org.example.text file:text/plain file:text/html file:application/xhtml+xml" |
| 23:17 | <Hixie> | which would mean that the cursor would be set to "copy" if any of the items in the drag data store had any of the given types, where the types refer to text items except if they start with "file:" in which case they're file types? |
| 23:19 | <Hixie> | or maybe dropzone="s:text/plain s:text/html f:text/plain f:text/html s:org.example.text copy" - each type has to start with f: or s: for files or strings, and there can be a "copy" keyword anywhere? |
| 23:20 | <MikeSmith> | yipes |
| 23:20 | <MikeSmith> | that looks pretty complicated |
| 23:20 | <MikeSmith> | error prone |
| 23:21 | <MikeSmith> | are you serious about that? |
| 23:21 | <Hixie> | well in practice it'd usually just be dropzone="move s:text/plain" |
| 23:21 | <Hixie> | or dropzone="f:image/png f:image/jpeg" |
| 23:22 | <Hixie> | is that that bad? |
| 23:22 | <Hixie> | i dunno how else to do it really |
| 23:23 | <Hixie> | i think we need a prefix just so that we have room in the lexical space to add features |
| 23:23 | <MikeSmith> | I'm trying to think of some precedents |
| 23:23 | <MikeSmith> | some other attributes with that kind of microsyntax |
| 23:24 | <MikeSmith> | and honestly I'm also thinking about, That's gonna suck if I have to be the one to write the datatype checking for it in the validator |
| 23:25 | <MikeSmith> | the validator really needs some additional contributors |
| 23:25 | <MikeSmith> | especially ones that are happy to do all the time-consuming and unrewarding implementation parts |
| 23:25 | <MikeSmith> | so I'm sure we're going to have a lot of people lining up for that job |
| 23:26 | <MikeSmith> | it might even surpass the long line of editors we have waiting to write specs |
| 23:27 | <MikeSmith> | Hixie: anyway, looking at it objectively, I guess it ain't so bad |
| 23:27 | <MikeSmith> | if it's going to be done declaratively |
| 23:28 | <Hixie> | it's simpler than the JS equivalent, at least |
| 23:29 | <karlcow> | dropzone="str(text/plain, text/html, org.example.text) file(text/plain, text/html) copy" |
| 23:31 | <karlcow> | hmm not sure it is more readable. |
| 23:33 | <Hixie> | harder to parse, too |
| 23:33 | <MikeSmith> | yeah |
| 23:34 | <MikeSmith> | Hixie: what does "link" do? |
| 23:34 | <MikeSmith> | like a symlink? |
| 23:34 | MikeSmith | goes to read the current spec |
| 23:34 | <Hixie> | yeah |
| 23:34 | <MikeSmith> | ah, OK |
| 23:34 | <Hixie> | think url dragged to desktop |
| 23:34 | <MikeSmith> | OK |
| 23:34 | <MikeSmith> | is that new-ish? |
| 23:34 | <Hixie> | nope |
| 23:35 | <Hixie> | link, move, and copy were the three types IE supported from the start |
| 23:35 | <MikeSmith> | man, I need to actually read this stuff |
| 23:35 | Hixie | finds a bit he forgot to spec out |
| 23:35 | <Hixie> | oops |
| 23:35 | <MikeSmith> | or actually, remember it |
| 23:38 | <MikeSmith> | Hixie: this is probably a dumb thought, but I would think it'd be a lot less error-prone if it essentially used keywords instead of mime types |
| 23:38 | <MikeSmith> | or commonly recognized extensions |
| 23:38 | <Hixie> | well technically it's whatever the author uses |
| 23:38 | <Hixie> | the spec doesn't require it to be a mime type |
| 23:39 | <Hixie> | it only uses mime types for things from the OS |
| 23:39 | <MikeSmith> | I see |
| 23:39 | <Hixie> | since different OSes use different type mechanisms for the drag-and-drop and clipboard mechanisms, and mime types are the least crazy of them |
| 23:39 | <Hixie> | that i have found |
| 23:39 | <Hixie> | and we need a single common one to use on all platforms |
| 23:39 | <Hixie> | for the web |
| 23:42 | MikeSmith | notices slinkcoding is here |
| 23:42 | <MikeSmith> | slinkcoding: hey, glad to see you here |
| 23:43 | MikeSmith | guesses slinkcoding might either be sleeping or out doing something fun since it's Friday night at 00:45 in Budapest |
