| 07:44 | <Ms2ger> | "Revive E4X as EXQO with extended SAX as Methods!!!!!" |
| 07:53 | jgraham | worries for Ms2ger's sanity |
| 07:53 | <Ms2ger> | You and me both |
| 09:55 | <MikeSmith> | SAX is so good it doesn'T need to be extended |
| 09:56 | jgraham | wonders if MikeSmith is being held hostage by XML terrorists |
| 09:57 | <MikeSmith> | tee hhee |
| 09:57 | <MikeSmith> | stockholm syndrome |
| 09:59 | <MikeSmith> | http://instagram.com/p/JzmkwQCr7y/ |
| 10:02 | <Ms2ger> | MikeSmith, not sure that's a think one'd like to be called |
| 10:08 | <MikeSmith> | yeah that's what makes it even better |
| 10:10 | <Ms2ger> | A think? |
| 10:10 | Ms2ger | blames XML |
| 10:11 | <MikeSmith> | if it'd been HTML it would have error-recovered from that for you automatically |
| 10:16 | <jgraham> | I really can't work out if "the ascii of the future" is supposed to be a compliment or not |
| 10:37 | <hsivonen> | MikeSmith: I've redeployed validator.nu, despite it being a bad idea right before heading out of office for a couple of weeks |
| 10:40 | <hsivonen> | TabAtkins: thanks for Python map() advice |
| 10:41 | <hsivonen> | MikeSmith: I landed a quick map/lambda hack to paper over the shell script generation bug without correctly fixing all possible future cases |
| 10:41 | <hsivonen> | (bad, I know) |
| 10:41 | <hsivonen> | MikeSmith: if in the future we want a command line switch that both contains a space and requires shell variable expansions, things will break again |
| 10:43 | <MikeSmith> | hsivonen: thanks much man |
| 10:44 | <MikeSmith> | hsivonen: I'll try not to add any new switches to the script at all. We got plenty already |
| 10:47 | <MikeSmith> | hsivonen: the ones I've added are of marginal benefit anyway. They're mostly just there to allow some things for the W3C service to be slightly different. e.g., the space thing was caused by me adding a switch to allow the UA string to contain a URL for page that explains what the validator is |
| 10:48 | <MikeSmith> | hsivonen: some sites admins, otherwise not knowing what the validator is, send us complaints about it violating robots.txt and things, or even blocking it |
| 10:49 | <MikeSmith> | hsivonen: anyway, thanks again -- I appreciate it |
| 14:09 | <smaug____> | what does "Let form document be the form's Document." mean ? |
| 14:09 | <smaug____> | is that ownerDocument? |
| 14:19 | <smaug____> | Hixie: am I interpreting the spec correctly, and that means ownerDocument ? |
| 14:19 | <smaug____> | "The Document of a Node (such as an element) is the Document that the Node's ownerDocument IDL attribute returns." |
| 14:29 | <Ms2ger> | Yep |
| 14:34 | <smaug____> | and browsers behave differently there |
| 15:49 | <Hixie> | smaug____: yeah |
| 15:51 | <smaug____> | Hixie: what about "the Document object with which subject in question is associated." |
| 15:51 | <smaug____> | in hyperlink handling |
| 15:51 | <smaug____> | that Document is also ownerDocument? |
| 15:51 | <Hixie> | associated usually means something else |
| 15:51 | <Hixie> | let me see |
| 15:52 | <Hixie> | looks like in this case it's just ownerDocument, yeah |
| 15:52 | <Hixie> | that could probably be phrased more obviously |
| 15:53 | <Hixie> | actually all of this stuff probably could be better phrased now |
| 15:53 | <Hixie> | at the time it was written, ownerDocument wasn't formally specced |
| 15:53 | <Hixie> | but now we have anne's dom spec, it might be easier to reference it |
| 15:53 | <Hixie> | ah, yeah, the dom spec now defines "the node document" |
| 15:53 | <smaug____> | looks like browsers handle this kind of cases in different ways |
| 15:54 | <smaug____> | blink doesn't care whether element is in doc, but gecko and trident do |
| 15:54 | <Hixie> | i should just change all of this stuff to just refer directly to "node document" instead of the round-about way i had to use before |
| 15:55 | <Hixie> | the spec doesn't care, does it? whether the element is in a doc or not? |
| 15:55 | <Hixie> | for following hyperlinks, i mean |
| 15:55 | <smaug____> | what I'm starting to do is to go through this stuff and think how it should work in shadow dom |
| 15:55 | <smaug____> | Hixie: right. and I think that is probably wrong |
| 15:55 | <Hixie> | why? |
| 15:55 | <Hixie> | security, compat? |
| 15:55 | <Hixie> | something else? |
| 15:56 | <smaug____> | something else |
| 15:56 | <smaug____> | saner behavior |
| 15:56 | <smaug____> | but probably doesn't matter much |
| 15:58 | <bkardell__> | Hixie: You around? |
| 15:58 | Ms2ger | grumbles |
| 15:58 | <Hixie> | smaug____: i think for some things (form submission in particular, also audio playback, img loading) we have a compat need to handle it while it's not actually in a doc, so for consistency we probably shouldn't artificially check it elsewhere |
| 15:58 | <Hixie> | bkardell__: 'sup |
| 15:58 | <smaug____> | form submission doesn't work in Gecko and Trident when not in doc |
| 15:58 | <Hixie> | smaug____: (i filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26310 btw) |
| 15:58 | <smaug____> | so no compat |
| 15:58 | <bkardell__> | Hixie: Trying to figure out which list to even send this question to man... |
| 15:59 | <bkardell__> | Hixie: Have a look at this https://gist.githubusercontent.com/bkardell/7da8ba03e690f2c24503/raw/ccbd20fc406f3158b0c616770e4bed1e956ce019/mutationobserverquestion.html |
| 15:59 | <Hixie> | smaug____: really? i thought we just found there was a compat need for something like that, when doing the rAc stuff. |
| 15:59 | <bkardell__> | Hixie: Whoops, running with mime type https://rawgit.com/bkardell/7da8ba03e690f2c24503/raw/ccbd20fc406f3158b0c616770e4bed1e956ce019/mutationobserverquestion.html |
| 16:00 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLFormElement.cpp#1595 |
| 16:00 | <bkardell__> | Hixie: The question is - a) shouldn't that output the same in all browsers b) what is under-specified or buggy in existing if do |
| 16:00 | <bkardell__> | s/do/so |
| 16:00 | <Hixie> | smaug____: huh |
| 16:00 | <Hixie> | smaug____: well anyway, the other cases stand |
| 16:01 | <smaug____> | I could buy that consistency argument |
| 16:02 | <Hixie> | bkardell__: if it's a mutation observer question, probably whatwg⊙wo, cc anne |
| 16:02 | <bkardell__> | Hixie: yeah, anne was suggesting maybe it was about pasing... maybe still best to send to the list |
| 16:03 | <bkardell__> | Hixie: just trying to shortcut list confusion |
| 16:03 | <Hixie> | bkardell__: pasing? |
| 16:03 | <bkardell__> | s/pasing/parsing :) |
| 16:03 | <smaug____> | bkardell__: note, Gecko's behavior changed recently |
| 16:03 | <Hixie> | bkardell__: oh |
| 16:03 | <Hixie> | bkardell__: /me looks closer |
| 16:03 | <smaug____> | bkardell__: though, I assume you're testing with latest versions |
| 16:04 | <smaug____> | not release versions |
| 16:04 | <Hixie> | bkardell__: oh if you're getting mutation observers during parsing, you can't guarantee that you'll get the same thing even in the same browser |
| 16:04 | <bkardell__> | smaug___: Checking in release versions |
| 16:04 | <Hixie> | bkardell__: it depends on TCP packet boundaries, amongst other things |
| 16:04 | <smaug____> | bkardell__: not useful |
| 16:04 | <bkardell__> | Hixie: why not? The way the test is constructed, there shouldn't be major variation, right? |
| 16:05 | <smaug____> | but yeah, packet boundaries may affect to characterData records |
| 16:06 | <Hixie> | bkardell__: e.g. at the simplest level, if one load gets an event loop spin (e.g. because the data was split into two packets and it only got the first packet) half way through the </h1> being parsed, and a second load does it all as one task, then the first will fire the mutation observers as two microtasks (at least), and the second will fire them as one. |
| 16:06 | <Ms2ger> | TIL: treatment of img@hspace is not interoperable |
| 16:07 | <bkardell__> | Hixie: Ok, I'll buy that for character data, but for element nodes they should be the same, yes? |
| 16:07 | <bkardell__> | smaug___: what do you see for type 1 nodes in latest FF? |
| 16:07 | <Hixie> | bkardell__: well at the very minimum they'll be fired with different microtask timings |
| 16:08 | <bkardell__> | Hixie__: the test doesn't really involve timings though, right? I mean, ignore text nodes in the output... |
| 16:09 | <smaug____> | bkardell__: FF has one characterData which chromium apparently doesn't have |
| 16:09 | <Hixie> | bkardell__: i don't really understand the test output |
| 16:09 | <smaug____> | (I don't understand those numbers under childList, but they are the same in FF and Chr) |
| 16:11 | <bkardell__> | childlist contains a count of nodeType for each addedNode |
| 16:11 | <Hixie> | bkardell__: the parser can result in observably different results because of timings, but the end result DOM should be the same. If the question is about timings, then the parser might be relevant. If the question is about the end-result, then that's probably a DOM question, not a parser question. |
| 16:11 | <bkardell__> | the source is pretty simple, fits on a visible screen |
| 16:12 | <zcorpan> | hsivonen: MikeSmith: validator.nu/?doc=http%3A%2F%2Fscottjehl.github.io%2Fpicturefill%2F&showsource=yes gives an internal error |
| 16:12 | <bkardell__> | smaug___: Let me check nightly |
| 16:12 | <Hixie> | bkardell__: you're assuming one understands the mutation observer API enough to understand the test :-) |
| 16:12 | <MikeSmith> | zcorpan: yeah checking on it now |
| 16:16 | <bkardell__> | smaug___: excellent, right! nightly is matching! |
| 16:16 | bkardell__ | does a happy dance |
| 16:17 | <gsnedders> | I'm being such a stereotypical PL guy. "Let's just use SML!" |
| 16:20 | <bkardell__> | smaug___: any thoughts on why safari works fine for me with that test only if devtools are open? ever heard of that? |
| 16:20 | <Hixie> | well bummer |
| 16:20 | <smaug____> | no idea. I haven't used Safari for ages |
| 16:21 | <Hixie> | i added some checks to catch cases where the dev version of the spec referenced terms not defined in the dev version of the spec |
| 16:21 | <Hixie> | i fixed one, then made it tell me the total count, not just one at a time, and it found 3999 more occurrences. |
| 16:21 | <bkardell__> | hober: You here? |
| 16:32 | <MikeSmith> | zcorpan: found the cause but not going to get it fixed until another hour or so at least. Hope hsivonen will be able to re-redeploy before he needs to head away |
| 16:34 | <Ms2ger> | Hm |
| 16:34 | <Ms2ger> | If I do margin-top: 50%, what is that based off? Width? |
| 16:34 | <zcorpan> | yes |
| 16:35 | <Ms2ger> | Ta |
| 16:36 | <Ms2ger> | Do I need a link if my reftest files are called foo.html/foo-ref.html in wpt? |
| 16:36 | <jgraham> | Ms2ger: In theory, no |
| 16:37 | <Ms2ger> | In practice? |
| 16:37 | <jgraham> | But if the ref is reusable it's encouraged to use <link> to a standard file rather than -ref |
| 16:37 | <Ms2ger> | Not really |
| 16:37 | <bkardell__> | smaug___: When is that stuff supposed to land in release? |
| 16:37 | <jgraham> | Ms2ger: Can you make it reusable? |
| 16:38 | <Ms2ger> | Hmm, maybe I could reuse it |
| 16:38 | <Ms2ger> | Alright |
| 16:39 | <Ms2ger> | Or not really, actually |
| 17:55 | <MikeSmit1> | hsivonen: I just pushed a fix to the build repo. Without it, the <picture> checker will fail with a non-document "Oops" internal error. If you have time to re-reploy before you have to head away, great. If not, it can wait til you're back. |
| 17:55 | <MikeSmit1> | hsivonen: sorry for not having been more careful |
| 17:58 | <MikeSmit1> | zcorpan: thanks for the heads-up. I fixed the cause and http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fw3c-test.org%2Fconformance-checkers%2Fhtml%2Felements%2Fpicture%2Fpicture-isvalid.html is built and running from the source trunk |
| 17:59 | <MikeSmit1> | zcorpan: But for now the <picture> support is currently broken at both v.nu & h5.v.nu and the W3C validator in the same way |
| 18:01 | <MikeSmit1> | zcorpan: and I'm going to leave it that way at the W3C validator until hsivonen is able to re-deploy too. Which may not be until 2 weeks from now |
| 18:02 | <MikeSmit1> | and now I need to board yet another plane without wifi |
| 18:02 | <MikeSmit1> | back around in 15 or so hours |
| 19:29 | <zcorpan> | MikeSmit1: k |
| 19:35 | <smaug____> | dglazkov_: what does "Window object named properties [HTML] must access the nodes in the document tree." mean in shadow dom spec |
| 19:35 | <smaug____> | doesn't seem to belong to that spec at all |
| 20:45 | <gsnedders> | jgraham: wow, you appeared around html5lib, I am amaze ;P |
| 20:50 | <jgraham> | gsnedders: Well it wasn't an insanly complex PR |
| 21:49 | <smaug____> | dglazkov_: is iframe supposed to work in shadow dom ? |
| 21:50 | <gsnedders> | jgraham: I dunno, it's not the most elegent of code, but that's Py2 as it's defined, le sigh |
| 21:53 | <smaug____> | per spec no |
| 21:53 | <smaug____> | interestingly chrome actually loads the iframe content but doesn't render it |
| 21:54 | <smaug____> | h, hmm |
| 21:54 | <smaug____> | ah, yes, it does render it |
| 21:54 | <smaug____> | but that is a bug |
| 21:55 | <smaug____> | Hixie: "the furthest ancestor element node" doesn't mean anything cross shadom-DOM boundaries, right? |
| 22:02 | <TabAtkins> | smaug____: Do you mean "how does iframe work when it has a shadow root"? |
| 22:02 | <TabAtkins> | smaug____: And I believe any algorithm that look at the ancestor list should cross shadow boundaries and walk up the composed tree automatically. |
| 22:03 | <smaug____> | why? |
| 22:03 | <smaug____> | I mean per what spec? |
| 22:04 | <smaug____> | (I could agree iframe should load, but so far I haven't found any spec which says that) |
| 22:10 | <Hixie> | smaug____: no idea |
| 22:10 | <Hixie> | smaug____: i haven't updated any of my specs to handle shadow trees yet |
| 22:10 | <smaug____> | right, so what is implemented in blink is somewhat random |
| 22:11 | <TabAtkins> | smaug____: Unsure which of my comments your question is in response to. |
| 22:11 | <smaug____> | TabAtkins: to your comment "And I believe any algorithm that look at the ancestor list should cross shadow boundaries and walk up the composed tree automatically." |
| 22:12 | <TabAtkins> | Ah, kk. That's my personal belief, not one based on a spec ref. ^_^ But if the Shadow DOM spec doesn't define that, it should; for example, form elements inside of shadow DOM should be submitted when placed in an external <form>. |
| 22:12 | <smaug____> | hmm, how should session history work in case there are iframes in shadow dom (assuming those actually load something) |
| 22:13 | <smaug____> | TabAtkins: whaat? form elements should be submitted in that case? |
| 22:14 | <smaug____> | that is surprising |
| 22:15 | <smaug____> | if one just used radio buttons in shadow dom for some UI stuff, their value might get submitted accidentally |
| 22:15 | <Hixie> | yeah i don't think it's as simple as just everything should work like if it was one tree |
| 22:15 | <smaug____> | it should definitely be opt-in behavior to let data to leak out from the shadow dom in such case |
| 22:15 | <Hixie> | i think it probably needs to depend on the binding |
| 22:27 | <TabAtkins> | smaug____: Hm, valid point. |
| 22:28 | <TabAtkins> | Domenic: I've got a super-class that's not meant to be used; it's just a holder for default implementations of methods, as it's designed to be extended. Should I have its constructor throw, or produce a valid-but-useless object? |
| 22:28 | <TabAtkins> | Domenic: (Specifically, I'm defining a set of XXXColor classes for CSS, and have a CSSColor superclass over them. If the constructor should really work, it'll just return an object that represents transparent black, with no way to manipulate it.) |
| 22:30 | <TabAtkins> | Also, I'm using WebIDL to define the shape of these interfaces, but defining most of the methods by just saying "here's the JS implementation", which is interesting. |
| 22:32 | <Hixie> | i'd just not define a constructor |
| 22:32 | <TabAtkins> | Gotta have something there. |
| 22:33 | <TabAtkins> | I forget what happens if you don't define a constructor. |
| 22:33 | <Hixie> | in webidl, if you don't set a [Constructor], you just don't get one |
| 22:33 | <Domenic> | It defines a throwing constructor |
| 22:34 | <Domenic> | TabAtkins: if you can make the throwing constructor work in a JS polyfill without mega-hacks, then that might be best... but I think that breaks inheritance |
| 22:35 | <Domenic> | (by mega-hacks, I mean a constructor that doesn't throw when you pass it an unguessable secret, which all the subclasses know) |
| 22:35 | <TabAtkins> | Domenic: Why is that necessary? |
| 22:35 | <Domenic> | TabAtkins: why is what necessary? |
| 22:35 | <TabAtkins> | Allowing the subclasses to construct an instance of the superclass? |
| 22:36 | <Domenic> | TabAtkins: if the superclass has any internal state at all, then you need to call super() in the subclass constructor to initialize it |
| 22:36 | <Hixie> | not necessarily |
| 22:36 | <Hixie> | you could call an internal init() method, e.g. |
| 22:36 | <TabAtkins> | It doesn't have any. The interface is just some methods, and some static stuff hanging off of it. |
| 22:37 | <Domenic> | TabAtkins: nice, then I think throwing constructor is pretty sound |
| 22:37 | <TabAtkins> | Okay, cool. |
| 22:37 | <TabAtkins> | (It has a semi-constructor that takes a string and returns one of its subclasses, but that's exposed as a static method on the interface instead.) |
| 22:38 | <Hixie> | (i mean, Object has some internal state, and yet it's still fine for subclasses to throw even if they then have further subclasses that don't throw) |
| 22:38 | <Domenic> | TabAtkins: as long as it can be JS polyfilled I am happy, even if it's a bit unusual. |
| 22:38 | <Domenic> | Hixie: Object has no internal state |
| 22:38 | <Domenic> | Hixie: but I think you are right that an internal init() method would probably work |
| 22:38 | <Hixie> | Object has quite a lot of internal state :-) |
| 22:38 | <TabAtkins> | Usually when I use a useless superclass, I just give its constructor an empty body and don't worry about it, becasue I know I'm not going to try and construct it. ^_^ |
| 22:38 | <TabAtkins> | But I gotta handle authors doing weird stuff. |
| 22:39 | <Domenic> | It would be nice if we had mixins in some first-class way |
| 22:39 | <TabAtkins> | So I was just wondering which style is more idiomatic - throwing, or dumb object. |
| 22:39 | <TabAtkins> | Yes. Yes it would be. |
| 22:39 | <TabAtkins> | That's all I'm using the stupid thing for, after all. |
| 22:39 | <Domenic> | WebIDL implements/ES7 Object.mixin would not allow monkeypatching the mixin and getting those changes shared by all mix-targets |
| 22:39 | <TabAtkins> | Yeah. |
| 22:40 | <TabAtkins> | And allowing monkeypatching is precisely why I'm structuring these things the way I am. |
| 22:41 | <Domenic> | (the problem i usually have with throwing constructors is that instances of them somehow exist. but that is not what is going on here.) |
| 22:42 | <TabAtkins> | Right. |
| 22:42 | <TabAtkins> | Unless there's some voodoo I'm not thinking of, there's no way to actually get a CSSColor object. |
| 22:42 | <TabAtkins> | Reflection wouldn't allow that, would it? |
| 22:43 | <Domenic> | Nah, I can't see how |
| 22:43 | <TabAtkins> | Oh wait, damnit, this isn't the name I wanted. I was going to go with RGBACompatibleColor. |
| 22:43 | <Domenic> | They would have to be exposed through APIs in your specs |
| 22:44 | <Domenic> | Wait... OK this is just a thought experiment, but... |
| 22:44 | <Domenic> | You could define RGBACCPrototype = { ...methods... } |
| 22:44 | <Domenic> | then inherit from that object directly |
| 22:44 | <Domenic> | Instead of defining function RGBACC () { throw new TypeError; }; RGBACC.prototype = { ... methods ... } |
| 22:45 | <Domenic> | Ah, you lose static methods though |
| 22:45 | <TabAtkins> | I need an RGBACC itself, though, to hang some static methods off of. |
| 22:45 | <TabAtkins> | Yeah. |
| 22:45 | <Domenic> | And... that pattern (proto-only) is getting very far from idiomatic. |
| 22:47 | <TabAtkins> | Might be interesting to make this pattern more explicit in IDL with "abstract interface ...", which fails syntax checking if there are any non-static attributes, or any constructors, and which is prohibited to be constructed by specs. |
| 22:47 | <TabAtkins> | (You'd still be able to use it in IDL itself, to denote an attribute/method that takes/returns any subclass of the interface.) |
| 22:48 | <TabAtkins> | (Or maybe prohibit it from being used directly, and add another syntax construct like "subclass<AbstractFoo>" that must be used by attributes/methods.) |
| 22:48 | <TabAtkins> | (Where subclass<XXX> is only valid when XXX is an abstract interface.) |
| 22:49 | <TabAtkins> | Unsure if worthwhile, but capturing relatively complex idioms that we want to use consistently is what WebIDL is for. |
| 22:49 | <Hixie> | why would non-static attributes be not ok in an abstract interface? |
| 22:49 | <TabAtkins> | Because that implies there's state on an instance, but there are no instances, by definition. |
| 22:49 | <Hixie> | i mean, fundamentally, "interface" really means "abstract class". WebIDL doesn't have a "class" concept. |
| 22:49 | <TabAtkins> | And putting data attributes on a prototype is bad practice. |
| 22:50 | <Hixie> | Node has plenty of attributes |
| 22:50 | <TabAtkins> | WebIDL's "interface" is JS's "class". |
| 22:50 | <Hixie> | i don't think that's bad practice |
| 22:50 | <TabAtkins> | I know. It's bad practice. ^_^ |
| 22:50 | <zewt> | i find distinguishing "interface" from "class with virtual methods" to be a meaningless java-ism |
| 22:50 | <Hixie> | nah, Node isn't bad practice |
| 22:50 | <Hixie> | at least, not that part of it |
| 22:50 | <Hixie> | it's a quite sensible API |
| 22:51 | <TabAtkins> | If a data property is on a prototype, setting the property actually sets it on the prototype, changing it for *every instance*. That's almost never what you want. |
| 22:51 | <Hixie> | an attribute is fundamentally no different than a method |
| 22:51 | <zewt> | i think the underlying reason java has it is to avoid issues like diamond inheritance, but there are better solutions to that |
| 22:51 | <TabAtkins> | And if it is, you can explicitly say so with a getter/setter pair. |
| 22:51 | <Hixie> | there's no difference between getter/setter pairs and data attributes in webidl |
| 22:51 | <TabAtkins> | Hixie: The "fundamental" difference is that you don't set methods regularly. |
| 22:51 | <Hixie> | setFoo()/getFoo() is equivalent to "attribute foo" |
| 22:51 | <TabAtkins> | Hixie: Technically, sure, but that's just because the getter/setter pair handle typechecking for you. |
| 22:53 | <TabAtkins> | Hm, I guess they always set the value on the instance, though. (Or set hidden state on the instance, which is the same thing here.) |
| 22:53 | <TabAtkins> | So maybe it's not actually terrible. |
| 22:54 | <TabAtkins> | But still, making the constructor automatically throw with a standard message, and preventing accidentally using the interface directly in other things (thus making it less likely the spec author absentmindedly constructs an instance in prose) might be helpful. |
| 22:56 | <Hixie> | [NoInterfaceObject] is the usual way to prevent that kind of mistake |
| 22:56 | <TabAtkins> | That prevents you from hanging static things off the interface. |
| 22:57 | <TabAtkins> | And doesn't prevent the mistake at all - prose can still construct a [NoInterfaceObject] object. |
| 22:57 | <TabAtkins> | The constructor just isn't present on the global. |
| 22:57 | <Hixie> | oh, from prose |
| 22:58 | <Hixie> | yeah, dunno what's a good way to prevent that kind of mistake |
| 22:58 | <Hixie> | whatever you put in the spec, other spec writers have a tendency to think their case is special :-) |
| 22:58 | <Hixie> | (i include myself in this!) |
| 23:00 | <Domenic> | TabAtkins: seems like a reasonable thing, although I'd like a couple more use cases first. |
| 23:00 | <TabAtkins> | Domenic: Yeah, it's a use-case-count of 1 right now, which is too small to generalize from safely. |
| 23:00 | <TabAtkins> | Gotta hit 3 before it's reasonable. ^_^ |
| 23:06 | <zewt> | putting empty <img> blocks on top of images to break copy image location is the modern-day equivalent of alert("right click is not supported") |
| 23:20 | <Domenic> | oooh, that's evil, i've never seen it before |
| 23:21 | <zewt> | others put images in css background-images for the same reason |
| 23:22 | <zewt> | (there are valid reasons to do that, but often it's just to make it harder to get the image url) |