| 00:00 | <Hixie> | (in the context of drawing text to a Path object) |
| 00:00 | <Philip`> | Pathification |
| 00:00 | <dbaron> | oops, I see I was disconnected for 7 minutes in the middle of the conversation |
| 00:00 | <zewt> | that's just pathological |
| 00:00 | <Hixie> | (or of rasterising to a canvas) |
| 00:00 | <heycam> | text-to-path might be more understandable than "outlining" |
| 00:00 | <dbaron> | stroking? |
| 00:00 | <Hixie> | right now i have "laid out (rasterized or outlined)" |
| 00:01 | <Hixie> | dbaron: sadly "stroking" in a canvas context is used for other meanings already |
| 00:02 | <Hixie> | hm, crap, i also need an Element to handle 'em' units, 'larger', 'smaller', 'ex' units, and 'rem', 'vh', and 'vw' units, and the other v unit, in the context of Paths |
| 00:02 | <Hixie> | i think i definitely have to make Path objects come from a specific canvas |
| 00:03 | <Hixie> | but that means using canvas.getContext('2d').createPath() rather than new Path(), which sucks |
| 00:03 | <TabAtkins_> | new Path({context: foo}) |
| 00:03 | <zewt> | too bad rendering fonts as paths will lose grid alignment, so will look bad at font sizes used for normal text :| |
| 00:04 | <zewt> | font hinting is Really Important(tm) |
| 00:04 | <Hixie> | TabAtkins_: then people will ask why they need to give one, at least the other way they just curse me but don't ask why :-) |
| 00:04 | <TabAtkins_> | If they dont' give one, measure off the root element. |
| 00:04 | <Hixie> | zewt: this will likely mostly be used for text-on-a-path, so it's not a big deal |
| 00:05 | <Hixie> | TabAtkins_: that would mean you don't get your @font-face fonts if you're a scoped canvas |
| 00:05 | <Hixie> | TabAtkins_: but maybe that's ok |
| 00:05 | <TabAtkins_> | Hixie: Yeah, it's a simple answer, and as long as you provide a way to grab a Path with a <canvas> reference, it's easy to fix when it's important. |
| 00:06 | <Hixie> | yeah that might be the way to go |
| 00:06 | <TabAtkins_> | (Btw, an Element isn't necessary to handle the v* units, is it? Those are common to every element in the page.) |
| 00:07 | <Hixie> | yeah for those you need a Document, not an Element |
| 00:08 | <Hixie> | i can imply a Document more easily than an Element |
| 00:08 | <Hixie> | hm, i wonder if zewt's point above means that I should provide measureText() explicitly on paths |
| 00:08 | <Hixie> | i guess not really, since we don't give a coordinate for measureText() anyway |
| 00:09 | <Hixie> | so it can't be taking hinting into account |
| 00:10 | <zewt> | one other detail--if you're *animating* a text-in-a-path, you probably explicitly *don't* want hinting |
| 00:10 | <zewt> | since it'll probably make it jiggle around weirdly |
| 01:26 | <Hixie> | man, i've been writing specs for over a decade now, i wish people would stop suggesting i don't know how to do my job :-P |
| 01:26 | <zewt> | noob |
| 01:26 | <TabAtkins_> | Maybe you should do your job better? |
| 01:26 | <TabAtkins_> | ^_^ |
| 01:28 | <Hixie> | i guess so |
| 03:17 | <zewt> | pritchard's message sure suggests to me that the people designing "web intents" don't understand structured clone transfer at all (but I'll leave it to someone who knows and/or cares about web intents to explain that, in case there really is some weird special property of web intents that makes what he describes not completely wrong) |
| 03:59 | <Hixie> | zewt: is he one of the ones designing it? |
| 03:59 | <Hixie> | looking at intents is next on my list after i finish all this canvas work |
| 04:00 | <zewt> | don't think so (iirc editor list is all @google, though dvcs.w3.org is timing out for me at the moment) |
| 04:02 | <Hixie> | k |
| 04:38 | <MikeSmith> | zewt: dvcs.w3.org still timing out for you? |
| 05:03 | <zewt> | works now |
| 05:03 | <MikeSmith> | OK |
| 08:07 | <MikeSmith> | hsivonen: https://bitbucket.org/pfalcon/validator/changeset/72665dd71762 |
| 08:08 | <MikeSmith> | "Implements mock versions of servlet classes to feed data from command line to validating servlet." |
| 08:08 | <MikeSmith> | looks like that was written more than a year ago |
| 08:08 | MikeSmith | now tries to remember who was asking for something like this a couple weeks back |
| 08:13 | <annevk> | Hixie: tracing? |
| 08:13 | <MikeSmith> | scott_gonzalez: https://bitbucket.org/pfalcon/validator/changeset/72665dd71762 |
| 08:14 | <annevk> | I think Adobe uses e.g. trace bitmap; so you could have traceFont or some such |
| 08:15 | <MikeSmith> | scott_gonzalez: related to http://krijnhoetmer.nl/irc-logs/whatwg/20120228#l-597 |
| 08:37 | <Ms2ger> | !summon zcorpan |
| 08:37 | <annevk> | !summon heycam|away |
| 09:40 | annevk | gives another attempt at destroying [TreatNonCallableAsNull] |
| 10:39 | <zcorpan> | <input list> also has no reflecting idl attr |
| 10:41 | <heycam> | annevk, pong, though just about to go to bed |
| 10:41 | <heycam> | if it's just the list, I'll reply in the morning |
| 10:42 | <annevk> | yeah it was about the event handlerstuff |
| 10:42 | <annevk> | I have the feeling we're talking past each other |
| 10:42 | <annevk> | hopefully my latest list reply helps a bit |
| 10:42 | <annevk> | g'night |
| 10:44 | <heycam> | maybe, will take a fresh look in the sunlight :) |
| 11:48 | <zcorpan> | Zarro Boogs! |
| 11:49 | <zcorpan> | annevk: please regen :-) |
| 13:42 | <annevk> | a revert request against html5-diff? |
| 13:42 | <annevk> | you got to be fucking kidding me |
| 13:43 | <jgraham> | hahahahaha |
| 13:43 | <zcorpan> | what? |
| 13:43 | <jgraham> | What was the objection? "Not enough DRM?" |
| 13:43 | <jgraham> | s/?"/"?/ |
| 13:44 | <jgraham> | Oh no, it's our old friend longdesc |
| 13:47 | <zcorpan> | shouldn't that be an objection on the *HTML5* spec to not say that longdesc is obsolete? |
| 13:48 | <MikeSmith> | good times |
| 13:49 | <zcorpan> | annevk: have you got around to regen it btw? |
| 13:50 | <zcorpan> | i'm done fiddling with it now |
| 13:52 | <MikeSmith> | zcorpan, annevk: in HTML4 the value of the dir attribute was case-insensitive, but the HTML spec currently makes it case-sensitive |
| 13:52 | <MikeSmith> | I think that was probably not intentional |
| 13:52 | <MikeSmith> | and validator.nu currently treats it case insensitively |
| 13:53 | <zcorpan> | MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#enumerated-attribute |
| 13:53 | <MikeSmith> | should I file a spec bug? |
| 13:53 | <zcorpan> | it's still case insensitive |
| 13:53 | <MikeSmith> | oh |
| 13:53 | <MikeSmith> | hah |
| 13:53 | <MikeSmith> | ok |
| 13:53 | <annevk> | zcorpan: I can do that now then; took a while to get all the terms in specification-data |
| 13:54 | <zcorpan> | annevk: k, cheers |
| 13:54 | <MikeSmith> | zcorpan: I actually read that but when I read it, I read it as "ASCII case-sensitive" instead of "ASCII case-insensitive" |
| 13:54 | <MikeSmith> | which of course makes not sense |
| 13:54 | <MikeSmith> | I blame in on the Negra Modelo |
| 13:55 | <zcorpan> | btw, anyone know how "working group process [was] bypassed and circumvented"? |
| 14:00 | <annevk> | it seems Hixie made some kind of typo |
| 14:00 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/#dom-cva-checkvalidatity |
| 14:00 | <annevk> | not sure how to resolve that |
| 14:00 | <annevk> | I guess I will make the hyperlink match HTML for now |
| 14:00 | <annevk> | can you file a bug on HTML zcorpan so Hixie fixes that? |
| 14:01 | <annevk> | in particular "atity" should be replaced with "ity" |
| 14:01 | <zcorpan> | after fika |
| 14:01 | <annevk> | priorities :p |
| 14:04 | <annevk> | beautiful: http://dev.w3.org/html5/html4-differences/ |
| 14:06 | <MikeSmith> | goed work brothermans |
| 14:07 | <MikeSmith> | zcorpan: ^ |
| 14:07 | <MikeSmith> | seriously |
| 14:07 | <MikeSmith> | (despite the revert request) |
| 14:07 | <annevk> | yeah with API changes and everything |
| 14:10 | <MikeSmith> | beautiful document |
| 14:10 | <MikeSmith> | despite the "the faultfinder will find fault even in paradise" sour note mentioned earlier |
| 14:13 | <matjas> | annevk, zcorpan: shouldn’t http://dev.w3.org/html5/html4-differences/ mention `document.scripts` as well? (since `document.head` is mentioned) |
| 14:14 | <matjas> | or was that specced before? |
| 14:16 | <matjas> | also, the `input` event doesn’t seem to be mentioned |
| 14:23 | <annevk> | matjas: file a bug :) |
| 14:25 | <scott_gonzalez> | Thanks MikeSmith, I've got someone trying it out now. |
| 14:26 | <MikeSmith> | scott_gonzalez: super |
| 14:26 | <scott_gonzalez> | His first comments were: |
| 14:26 | <scott_gonzalez> | No Maven config or anything, but it depends on some other library in the same nu.validator package, not part of the project |
| 14:26 | <scott_gonzalez> | Readme says nothing about compiling the project... |
| 14:26 | <scott_gonzalez> | Of course that's not related to your specific commit. |
| 14:27 | <MikeSmith> | that's not my commit, actually |
| 14:27 | <MikeSmith> | I just stumbled across that |
| 14:27 | <scott_gonzalez> | Oh, heh, I didn't even look at who the committer was :-) |
| 14:28 | <MikeSmith> | anyway, somebody with minimal Java chops should be able to figure out things from there |
| 14:29 | <MikeSmith> | and lack of anything related to Maven is a feature :) |
| 14:36 | <matjas> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16244 |
| 14:37 | <annevk> | thanks! |
| 14:40 | <zcorpan> | matjas: scripts is documented in http://dev.w3.org/html5/html4-differences/Overview.src.html |
| 14:41 | <zcorpan> | matjas: events aren't well covered, might need their own section. could you file a bug? |
| 14:41 | <zcorpan> | oh you did |
| 14:43 | <zcorpan> | thanks |
| 14:43 | <matjas> | thank you |
| 14:43 | <matjas> | nice work btw you guys! |
| 14:43 | <matjas> | also, should something like document.innerHTML (which got added, then moved to a separate spec, then removed from that spec) be mentioned? |
| 14:44 | <annevk> | don't think so, never got implemented |
| 14:44 | <matjas> | k |
| 14:44 | <zcorpan> | that's something for http://platform.html5.org/history/ |
| 14:48 | <zcorpan> | MikeSmith: thanks |
| 14:50 | <zcorpan> | annevk: thanks for the help with anolis |
| 14:51 | <annevk> | you should try it some day |
| 14:51 | <annevk> | ;) |
| 14:52 | <zcorpan> | yeah i'll try to get it running for the next publication |
| 15:02 | <annevk> | hmm |
| 15:03 | <annevk> | WebKit is adding Number.toLocaleString() and such |
| 15:03 | <annevk> | not really sure if that is great or not |
| 15:16 | <zcorpan> | annevk: shouldn't the boilerplate be WD? |
| 15:17 | <annevk> | dunno are we done? |
| 15:17 | <annevk> | is there a pubdate? |
| 15:17 | <annevk> | s/we/you/ |
| 15:17 | <zcorpan> | i'm done if i get to decide |
| 15:18 | <zcorpan> | "We are planning to prepare and publish the drafts during the week of March 5 and probably on Tue March 6." |
| 15:18 | <zcorpan> | CfC: Publish ten heartbeat drafts as WDs |
| 15:20 | <annevk> | okay |
| 15:20 | <annevk> | made ready for publishing today |
| 15:21 | <zcorpan> | thanks |
| 15:23 | <zcorpan> | do we need to notify someone that it's ready, or something? |
| 15:24 | <zcorpan> | dang, forgot to update previous version links |
| 15:26 | <zcorpan> | added |
| 15:27 | <annevk> | you can reply to the chairs |
| 15:27 | <annevk> | maybe that'll remind them about the publication date :p |
| 15:27 | <zcorpan> | heh, ok |
| 15:28 | <zcorpan> | can you regen again? |
| 15:28 | <annevk> | done |
| 15:28 | <zcorpan> | excellent |
| 15:28 | <moo-_-> | is there a list of all html5 attributes of all elements? |
| 15:36 | <zcorpan> | the spec has an index |
| 15:36 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#attributes-1 |
| 15:36 | <zcorpan> | does not include obsolete attributes |
| 15:37 | <moo-_-> | zcorpan: thx |
| 16:22 | <zcorpan> | annevk: fyi, i won't be online for the rest of the day today (in case html5-diff needs a change or anything) |
| 16:22 | <annevk> | k |
| 16:22 | <annevk> | i might be tonight; we'll see |
| 16:22 | <zcorpan> | k, see ya |
| 16:40 | <annevk> | gb18030 error handling |
| 16:40 | <annevk> | aaaaargh |
| 16:41 | <[tm]> | eh? sabu arrested? |
| 16:41 | <annevk> | ? |
| 16:47 | <[tm]> | man |
| 16:47 | <[tm]> | this is grim |
| 16:48 | <[tm]> | news reports saying he's been collaborating with the FBI since June |
| 16:48 | <[tm]> | to incriminate everybody else |
| 16:49 | <[tm]> | dude apparently had kids |
| 16:49 | <[tm]> | and FBI used threat of taking his kiss away |
| 16:50 | <[tm]> | I hope none of this its true |
| 16:52 | <[tm]> | regardless, for every one sabu there are 100 more |
| 16:55 | <annevk> | not sure if opening the CDM floodgates so we can experiment to see if an RF implementation is possible is really the right strategy here... |
| 16:56 | <[tm]> | will just inspire |
| 16:56 | <[tm]> | oofs |
| 16:56 | <[tm]> | annevk: maybe those floodgates been already opened |
| 16:57 | <[tm]> | house on its way out the barn |
| 16:57 | <[tm]> | horse |
| 16:58 | <Philip`> | [tm]: I interpreted the "?" as meaning "I haven't got a clue who 'sabu' is, what on earth are you talking about?" |
| 16:59 | <annevk> | [tm]: there's plugins I guess |
| 17:00 | <jgraham> | I still haven't entirely grasped why it is not OK if a video requires a binary component called "Flash" that implements NPAPI, but is OK if it requires a binary component that isn't called "Flash" that implements some CDM API. But I haven't followed the discussion closely so maybe I shouldn't say anything at all |
| 17:01 | <annevk> | TabAtkins_: actually, browsers are more or less required to follow the HTML rendering section |
| 17:02 | <annevk> | TabAtkins_: not sure what it says about <table> and bordercolor though |
| 17:03 | <annevk> | jgraham: presumably plugins not being part of some platforms or disabled by default |
| 17:03 | <annevk> | jgraham: so you need plugins' |
| 17:03 | <annevk> | and plugins prime is <video> plugins I guess |
| 17:04 | <jgraham> | annevk: I still haven't grasped why it is not OK… well I just said that. But I don't see how requiring a binary API that is implemented some places is a win over requiring a binary API that is implemented nowhere |
| 17:06 | <Philip`> | Because it means the companies involved don't have to pay licensing fees to Adobe, while also saving the engineering effort of reimplementing the entire video API themselves? |
| 17:07 | <annevk> | and they can be on platforms that don't have Flash, but do have this |
| 17:07 | <jgraham> | Philip`: So it is an attempt to move the costs from the people profiting on video distribution to browser vendors? |
| 17:07 | <jgraham> | annevk: Do any such platforms exist? |
| 17:08 | <Philip`> | jgraham: That seems a possible hypothesis |
| 17:08 | <annevk> | jgraham: well Windows 8 seems to be sort of like that |
| 17:08 | <annevk> | jgraham: with plugins disabled by default |
| 17:09 | <annevk> | jgraham: Apple seemed interested as well, so you can add iOS to that |
| 17:11 | <Philip`> | Also everyone complains about Flash being crashy, which is presumably caused largely by it being very large and requiring lots of low-level platform integration, so it'd be a more technically robust design if you put a minimal amount of code behind a minimal binary API (providing just the encryption support and nothing else) |
| 17:11 | <[tm]> | sabu is sabu |
| 17:14 | <Philip`> | Also you might want a site that provides both DRMed and unrestricted videos (e.g. Youtube with a subset of videos having special restrictions), and not want to support two totally independent video APIs, so you'd either use <video> plus an optional DRM component (so non-DRM-supporting browsers could still play most of the videos) or you'd use a totally custom plugin-based video API (so those browsers would be locked out entirely) |
| 17:19 | <dglazkov> | good morning, hatwg! |
| 17:19 | <dglazkov> | man, hat wg |
| 17:19 | <dglazkov> | that does sound much more fan |
| 17:20 | <dglazkov> | fan->fun |
| 17:20 | <dglazkov> | I type sad. |
| 17:27 | <[tm]> | we're clearly months away from getting any resolution i |
| 17:27 | <[tm]> | on this |
| 18:24 | <hsivonen> | Philip`: If the CDM wants to do its own decoding, own painting, virtualization detection, screen recorder detection, etc., it won't be less low-level than Flash or easier to intergrate than an NPAPI plug-in |
| 19:58 | <AryehGregor> | What's the use-case for http(s)+aes? |
| 19:59 | AryehGregor | is actually surprised by how intelligent and amicable most of this DRM thread is |
| 20:00 | <othermaciej> | I think it only addresses the use case that people sort of claim to care about but which is not the primary motivation |
| 20:00 | <othermaciej> | yes, it seems pretty thoughtful and polite for such a controversial topic |
| 20:00 | <AryehGregor> | Someone from Google said YouTube is interested in it. |
| 20:01 | <AryehGregor> | Or at least in ClearKey, which is apparently more or less equivalent. |
| 20:01 | <Yuhong> | http://news.ycombinator.com/item?id=3606623 |
| 20:01 | <AryehGregor> | http(s)+aes seems like it only serves the DRM use-case if the key part of the URL isn't exposed to the user, or something like that. |
| 20:01 | <AryehGregor> | But authors can't rely on the browser to do that. |
| 20:02 | <AryehGregor> | Specifically, if the restriction is implemented in open-source code, even if all browsers ship with it (unlikely), it will only be a matter of time before someone writes a patched version. |
| 20:03 | <othermaciej> | ClearKey is not sufficiently specified for me to understand exactly what it does |
| 20:03 | <othermaciej> | but if it's meant to support key rotation, then http(a)+aes is not equivalent |
| 20:03 | <AryehGregor> | If the goal is to stop the user from getting a copy of the video, the best solution that's implementable in open-source seems like site-specific obfuscation of the underlying HTML and transport, like using transparent divs to block "Save As" and using one-time URLs so that grabbing the URL from the source won't help. |
| 20:03 | <othermaciej> | likewise if it's required for encryption to be inside the container instead of outside |
| 20:03 | <AryehGregor> | YouTube already does this, I think. |
| 20:04 | <AryehGregor> | Anything further seems unlikely to be implementable in open-source software. On the other hand, if you make it moderately inconvenient to extract the video from the site, it should be no problem, as long as a) it's at least as inconvenient as using BitTorrent, and b) the content is already available on BitTorrent. |
| 20:05 | <AryehGregor> | Then again, that's being rational, and the content owners are not necessarily being rational here. |
| 20:29 | <jgraham> | Oh, look at that. Someone ported SQLite to javascript (via Emscripten) |
| 20:30 | <AryehGregor> | Someone already ported Linux to JavaScript, and since then I've ceased to be amazed at any such feat. |
| 20:30 | <AryehGregor> | Once you have a full OS and compiler running on an x86 emulator, the rest is all details. |
| 20:30 | <AryehGregor> | (although I realize that this SQLite port is probably not running in a VM, the point holds) |
| 20:31 | <AryehGregor> | s/VM/emulator/ |
| 20:31 | <AryehGregor> | s!VM/emulator!a VM/an emulator! |
| 20:32 | <jgraham> | AryehGregor: Right, the linux port was clever but useless |
| 20:32 | <jgraham> | But people might actaully run webapps backed with SQLite |
| 20:32 | <AryehGregor> | Assuming there's a suitable storage layer. |
| 20:32 | <jgraham> | Yeah, fair point |
| 20:32 | <AryehGregor> | Which is a bit dicey right know AFAICT. |
| 20:32 | <jgraham> | I guess that will be IndexedDb |
| 20:33 | <jgraham> | Which will be sort of ironic |
| 20:33 | <AryehGregor> | Which requires user prompting currently to do anything, and (unlike SQLite) is asynchronous. Unless you want your SQLite library to only be accessible from workers. |
| 20:33 | <AryehGregor> | (maybe SQLite can be used asynchronously too, I dunno) |
| 20:33 | <AryehGregor> | (I guess you could always make the JS wrapper layer for SQLite asynchronous even if SQLite itself normally isn't) |
| 20:34 | <jgraham> | Right. You could have something like the WebSQL API but backed by javascript backed by IndexedDb |
| 20:34 | <AryehGregor> | Right. With another abstraction layer implementing IndexedDB on top of local storage for browsers that don't support it. |
| 20:35 | <jgraham> | Heh |
| 20:35 | <AryehGregor> | And then another one that falls back to Flash cookies or something. |
| 20:35 | <Philip`> | Would you end up using any of SQLite beyond its SQL parser/optimiser? |
| 20:35 | <AryehGregor> | Philip`, of course. You'd use IndexedDB by storing the entire SQLite database as one big database entry. Or alternatively, by storing each page as a separate database entry in a flat table. |
| 20:35 | <AryehGregor> | Probably per-page makes more sense. |
| 20:36 | <jgraham> | Maybe you could also make the backend one of these virtual-filesystem APIs that people have started developing |
| 20:36 | <AryehGregor> | I mean, abstraction layers are no fun if you don't reimplement the same abstractions at multiple levels so that you get all the inefficiency but none of the convenience. |
| 20:36 | <jgraham> | Although I guess they will take longer before they are universially avaliable |
| 20:37 | <AryehGregor> | That's why you have a polyfill that falls back to IndexedDB, then localStorage, then Flash cookies, then synchronous XHR to a server back-end that stores user-specific data based on an id. |
| 20:38 | <AryehGregor> | I mean, if you could rely on the availability of basic functionality, it would hardly be proper web development. |
| 20:40 | <jgraham> | Blame Microsoft/Google for not making it possible/easy to upgrade the default browsers on their respective OSes? |
| 20:42 | <jgraham> | (it wouldn't be the whole story ofc but it would get you some of the way there) |
| 20:42 | <Yuhong> | "This section discusses this issue, providing various elements of comparison and what it would take to allow authors to actually use OBJECT instead of IFRAME. " |
| 20:42 | <Yuhong> | http://www.w3.org/TR/WD-frames-970331.html |
| 20:56 | <Hixie> | AryehGregor: the point of http+aes is to enable someone to store private content on a CDN that is trusted not to vandalise data but isn't trusted not to passively copy data |
| 21:58 | <rniwa> | annevk: yt? |
| 22:45 | <Hixie> | what's a good term for the path that the canvas 2d context has? |
| 22:45 | <Hixie> | ideas so far: |
| 22:45 | <Hixie> | implicit path |
| 22:45 | <Hixie> | global path |
| 22:45 | <Hixie> | default path |
| 22:46 | <Hixie> | context path |
| 22:46 | <Hixie> | default context path |
| 22:46 | <Hixie> | legacy path |
| 22:47 | <Hixie> | i'll go with "Default path" i think |
| 22:49 | <Hixie> | heycam: fwiw, i just narrowly avoided an interesting webidl problem |
| 22:50 | <heycam> | Hixie, yeah? |
| 22:50 | <Hixie> | heycam: some code relies on the order of arc() and arcTo() on the canvas API |
| 22:50 | <heycam> | Hixie, the order when enumerating properties on the canvas context object? |
| 22:50 | <Hixie> | heycam: and i was safe only because in splitting the api, those two methods ended up in the same interface |
| 22:50 | <Hixie> | heycam: yeah |
| 22:50 | <Hixie> | heycam: it's possible that one day the relative order of methods in two different interfaces both imported into another interface will matter |
| 22:51 | <zewt> | "shoot the programmer in the head" |
| 22:51 | <heycam> | Hixie, well currently the order is not significant at all according to the spec |
| 22:51 | <Hixie> | heycam: ah. well then. i have news for you :-) |
| 22:51 | <heycam> | Hixie, i.e. order of interface importing or declarations does not impact property enumeration order |
| 22:51 | <Hixie> | heycam: see https://bugzilla.mozilla.org/show_bug.cgi?id=623437 and its dupes |
| 22:52 | <Hixie> | heycam: right now in the spec i'm intentionally maintaining the relative order of arc() and arcTo() |
| 22:53 | <heycam> | Hixie, that shouldn't matter -- the spec doesn't do anything with the order operations appear |
| 22:53 | <Hixie> | heycam: (though i'm not explicit about that, it's just a comment in the source to remind me not to switch them) |
| 22:53 | <heycam> | Hixie, if some implementations choose to interpret the order they appear on IDL in some way, then that's their choice :) |
| 22:53 | <heycam> | (this of course is beacuse Web IDL doesn't prescribe property enumeration order) |
| 22:53 | <Hixie> | heycam: well, if pages depend on an order, it's going to be our problem :-) |
| 22:53 | <heycam> | yeah |
| 22:54 | <Hixie> | heycam: anyway, i'm fine with not having an order if we can get away with it. just thought you should know about it. |
| 22:54 | <Hixie> | heycam: for now i'll continue to maintain the order as is in case you make it significant |
| 22:54 | <heycam> | Hixie, thanks for the pointer |
| 22:54 | <Hixie> | np |
| 22:54 | <heycam> | Hixie, I suspect we will have to define it at some point |
| 23:09 | <rniwa> | AryehGregor: so resize css property won't work for control selection because resize property isn't applicable to replaced elements :( |
| 23:29 | <roc_> | really? |
| 23:29 | <Hixie> | i don't understand how the resize property is supposed to work at all |
| 23:30 | <gsnedders> | Hixie: As long WebIDL is based on ES5, I'm not sure it can ever define an order. |
| 23:31 | gsnedders | would need to check what ES5 says about host object enumeration order tohugh |
| 23:31 | <gsnedders> | *though |
| 23:31 | <Hixie> | why ever not? |
| 23:31 | <gsnedders> | Hixie: Well, it would be contradicting something below it in the stack |
| 23:31 | <Hixie> | HTML depends on ES5 and it defines that the global scope object and 'this' aren't the same object... |
| 23:32 | <Hixie> | contradicting something below it in the stack isn't hard to do, it's just something to avoid to do if possible |
| 23:33 | <gsnedders> | Ah, no, host objects can define enumeration orders. |
| 23:33 | <Hixie> | when it's not possible, e.g. because the spec you depend on refuses to fix itself, you just override it |
| 23:33 | <gsnedders> | Hixie: Nothing was specified in ES5 because there was no consensus |
| 23:33 | <gsnedders> | Whatever it spec'd likely wouldn't have been implemented by half of the major ES engines |
| 23:34 | <Hixie> | if it ain't implemented by half the engines, then it's not required |
| 23:35 | <gsnedders> | Hixie: Ah, no. Everyone who had deviated from the historical norm (i.e., Opera 10.50+, IE9+, Chrome) knew it caused compat breakage, but deemed it a worthwhile change. |
| 23:36 | <Hixie> | if they are able to make the change, it's not required |
| 23:36 | <Hixie> | by definition |
| 23:36 | <gsnedders> | Some people would say that having yahoo.jp work was required. |
| 23:36 | <gsnedders> | (I believe the site has since changed) |
| 23:37 | <Hixie> | if multiple browsers shipped without it working, then by definition those people are wrong |
| 23:37 | <gsnedders> | Still, given that it *did* break things, others don't want. |
| 23:38 | <Hixie> | i'm not sure what you're arguing :-) |
| 23:38 | <gsnedders> | It's hard to convince people to break legacy content, even when some already have. |
| 23:39 | <gsnedders> | And hence hard to reach consensus, when the side that has gone for the behaviour better from a perf/memory POV doesn't want to regress, and the other side doesn't want to break sites that the others already have. |
| 23:39 | <Hixie> | my only arguments here are that there are two states: either a feature is required and eveyone wants to implement that thing, in which case either the relevant spec needs to be fixed or a spec above it on the stack needs to fix it by contradicting it intentionally, or, there's not a requirement to implement the feature, in which case neither spec needs to do anything. consensus is a red herring here, unless by it you mean "agreement amongst a majority of relevant i |
| 23:40 | <Hixie> | (which is not what people usually mean by "consensus") |
| 23:41 | <gsnedders> | Hixie: By consensus I mean amongst browser vendors |
| 23:42 | <gsnedders> | (who don't have consensus on which of the two states you gave above) |
| 23:43 | <Hixie> | by definition, if people don't agree something is required, then we're in the second state |
| 23:44 | <Hixie> | especially in this case where the second state's allowed implementations is a superset of the first state's |