| 00:04 | <jamesr__> | Hixie: do you want to spec what browsers do or what you want them to do? |
| 00:08 | <jamesr__> | if you want to say "all major UAs ignore this section of the spec and always will" then go ahead |
| 00:12 | <Hixie> | i _want_ to spec what i want them to do and then have them follow it :-P |
| 00:13 | <Hixie> | but what i want is hardly relevant here |
| 00:13 | <Hixie> | jamesr__: the spec does describe what browsers do, since it gives two options (corrupt data, or use locks) |
| 00:15 | <zewt> | sounds like it's really describing just one thing, since "use locks" is a subset of "corrupt data" ("corrupt N bytes of data" where N might be 0) |
| 00:15 | <zewt> | in other words, it may as well be non-normative "it'd be nice if you did this" instead of hand-wavey normative language |
| 00:16 | <Hixie> | ? |
| 00:16 | <Hixie> | "corrupt data" is not the same as "don't corrupt data"... |
| 00:16 | <zewt> | no, it's a superset of it |
| 00:16 | <Hixie> | no, they're mutually exclusive |
| 00:16 | <zewt> | the amount of data corrupted might happen to be zero, which is equivalent to not corrupting data |
| 00:18 | <Hixie> | that's like saying that stabbing yourself is a superset of not stabbing yourself because you might miss. |
| 00:18 | <zewt> | i guess the real sort-of-detectable distinguishing point has nothing to do with corruption (or not) of data, but of scripts blocking each other in different tabs |
| 00:18 | <Hixie> | the corruption is quite detectable... |
| 00:19 | <Hixie> | the only reason the storage mutex exists is to provide an interoperable way to avoid corruption |
| 00:21 | <zewt> | put differently, is there something the storage mutex option allows browsers to do that they would otherwise be prohibited from doing? |
| 00:22 | <Hixie> | no, it prohibits things, it doesn't allow things |
| 00:22 | <Hixie> | it defines observable behaviour |
| 00:22 | <Hixie> | that is required (if the browser opts in to it) |
| 00:23 | <TabAtkins> | MikeSmith: I'm trying to fix the Editing spec to refer to its stylesheet over https, now that Hixie fixed that issue. But I get access denied when pushing to the /hg/editing/ repo. Can you fix this? |
| 00:23 | <Hixie> | (and which really should be required of all browsers, but some vendors feel data corruption is no big deal compared to performance of multiple similar-origin tabs) |
| 00:23 | <Hixie> | TabAtkins: thanks for doing that |
| 00:23 | <TabAtkins> | np |
| 00:24 | <zewt> | well, that's the point: giving an option B that does nothing but prohibit things allowed by option A isn't an extra option; they can do it anyway, since if you implement B, you've implemented the requirements of A too |
| 00:24 | <zewt> | anyway |
| 00:24 | <zewt> | the consequences aren't explosions, just a bit of noise in the spec |
| 00:27 | <Hixie> | zewt: there are multiple ways to implement not corrupting data, certainly, but some would be detectably not the same as what the spec allows |
| 00:27 | <Hixie> | zewt: (for example, you could do the storage mutex thing but not implement the yield API) |
| 00:29 | <Hixie> | jamesr__: (if you do want something in the spec, please file a big at http://whatwg.org/newbug and i'll get to it asap -- i'm in the middle of the focus model rewrite so i can't do it right now) |
| 00:37 | <jamesr__> | bug filed. a spec's no place for wishful thinking, as sad as the current state is |
| 03:52 | <MikeSmith> | TabAtkins: try now |
| 05:37 | <TabAtkins> | MikeSmith: I'll try in the morning. Thanks! |
| 05:39 | <MikeSmith> | k |
| 09:33 | <Ms2ger> | And document.all() restored |
| 09:43 | <annevk-cloud> | That was quick |
| 09:43 | <annevk-cloud> | .tags still dead? |
| 09:47 | <Ms2ger> | Yeah |
| 09:51 | <zcorpan> | 0.03% is too damn high |
| 09:52 | <Ms2ger> | And the fact that someone noticed that their bank broke within a week :/ |
| 09:54 | <annevk_> | esprehn: I think you forgot to reply |
| 09:54 | <zcorpan> | bratell's point seems relevant here (we need to know *which* URLs will break, not just how many pageviews) |
| 09:54 | <annevk> | Maybe Opera should do its own telemetry ;-) |
| 09:56 | <zcorpan> | for finding urls i think the conclusion was that a separate research is needed (like webdevdata but better) |
| 10:10 | <zcorpan> | TIL: 'errorVideo' is a really bad variable name |
| 10:11 | <darobin> | zcorpan: how so? |
| 10:12 | <zcorpan> | darobin: i failed to type it correctly in all places i intended to use the variable |
| 10:12 | <zcorpan> | first as 'video' and then 'videoError' |
| 10:12 | <darobin> | haha |
| 10:12 | <zcorpan> | but it could be that i just suck |
| 10:13 | <darobin> | well, if it makes you feel any better, I'm getting close to 20 years of programming and I still can't type "length" without getting it wrong at least once |
| 10:13 | <darobin> | this, of course, shows that I'm just dying to become a Python lover |
| 10:14 | <zcorpan> | i think my most common typo is documetn |
| 10:14 | <zcorpan> | maybe i should make a PR to add that to the dom spec |
| 10:14 | <darobin> | lol |
| 10:15 | <darobin> | my favourite standards typo is "specifiction" |
| 10:15 | <darobin> | https://www.google.com/search?q=specifiction+site%3Aw3.org&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb |
| 10:15 | <annevk> | darobin: coming from a W3C employee, doesn't seem like it has to be a typo :p |
| 10:16 | <darobin> | annevk: my point exactly |
| 10:17 | <darobin> | annevk: quite fittingly, it shows up in the GCGP introduction http://www.w3.org/TR/2006/WD-css3-gcpm-20060919/ |
| 10:18 | <darobin> | GCPM |
| 10:18 | <darobin> | I reckon I'll actually call my next company "Specifiction" |
| 10:20 | <annevk> | darobin: hehe |
| 11:09 | <Ms2ger> | Since some people seem to be confused about what's happening to document.all: http://lists.w3.org/Archives/Public/www-archive/2014Feb/0012.html |
| 11:25 | <zcorpan> | wpt-serve documentation isn't so discoverable from web-platform-tests or even testthewebforward.org |
| 11:25 | <jgraham> | zcorpan: No. That seems fixable though |
| 11:26 | <darobin> | zcorpan: just go ahead and patch the readme maybe? |
| 11:27 | <zcorpan> | no i prefer to whine in irc and hope someone else fixes it while i enjoy my soup with bacon :-) |
| 11:27 | <jgraham> | And pancakes? |
| 11:28 | <zcorpan> | no pancakes |
| 11:28 | <jgraham> | Breaking with tradition there |
| 11:29 | <zcorpan> | wrong kind of soup to boot |
| 11:29 | <jgraham> | They'll take away your passport if you're not careful |
| 11:30 | <zcorpan> | nsa has my back |
| 11:51 | <annevk> | Where is Ms2ger? |
| 11:56 | <jgraham> | annevk: Is this a new series of books? |
| 11:56 | <jgraham> | You have to spot Ms2ger, but you don't get to know what he looks like |
| 11:56 | <annevk> | Why is jgraham obtuse? |
| 11:57 | <annevk> | Who is MrLastWeek really? |
| 12:47 | <zcorpan> | TabAtkins: i cloned the repo, but i don't have bikeshed installed on this computer so i thought i'd upload to https://api.csswg.org/bikeshed/ instead |
| 12:52 | <zcorpan> | Hixie: if you put the stylesheet in resources.whatwg.org it'll get synced to https://w3c-test.org/resources.whatwg.org/ |
| 12:57 | <zcorpan> | oh you got a cert now, ok |
| 13:40 | <bhanu__> | annevk: for surroundContents method, won't HierarchyRequestError be thrown any more as per http://dom.spec.whatwg.org/#dom-range-surroundcontents? |
| 13:41 | <annevk> | bhanu__: surroundContents is defined in terms of several other methods that can throw that exception |
| 13:42 | annevk | is studying a range bug as well; https://www.w3.org/Bugs/Public/show_bug.cgi?id=17541 |
| 13:45 | <Ms2ger> | Ohi annevk |
| 13:45 | <annevk> | Ms2ger: I'm thinking of fixing the insertAdjacent stuff |
| 13:45 | <Ms2ger> | Which? |
| 13:45 | <annevk> | Ms2ger: adding the two methods |
| 13:45 | <Ms2ger> | Which? |
| 13:46 | <annevk> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962 ? |
| 13:46 | <annevk> | Ms2ger: and if we do that I sort of feel we should also merge DOM Parsing into DOM at some point |
| 13:46 | <Ms2ger> | Why would you add those? |
| 13:46 | Ms2ger | looks |
| 13:46 | <annevk> | Ms2ger: see the bug |
| 13:47 | <zcorpan> | TabAtkins: ignoring the biblio thing, api.csswg.org/bikeshed gives me "UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 4282: ordinal not in range(128)" although my source just has ascii (i guess some reference has non-ascii) |
| 13:47 | <Ms2ger> | Given that nobody actually filed a Firefox bug about it in the past decade, I'd rather leave it out |
| 13:49 | <annevk> | Ms2ger: what's your plan to get others to remove them? |
| 13:49 | <Ms2ger> | Whine? |
| 13:50 | Ms2ger | goes back to paying attention to class |
| 13:56 | <bhanu__> | annevk: ok |
| 14:00 | <Ms2ger> | Styling on https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html works again |
| 14:04 | jgraham | wonders if we can make annevk's official title "Brahma of Web Components" |
| 14:05 | <Ms2ger> | Barman of Web Components? |
| 14:05 | <jgraham> | Hmm, that might be the wrong god |
| 14:05 | <annevk> | "According to the Brahmā Purāņa, he is the father of Manu, and from Manu all human beings are descended." o_O |
| 14:06 | <jgraham> | Vishnu |
| 14:06 | <jgraham> | Dammit |
| 14:06 | jgraham | starts again |
| 14:06 | jgraham | wonders if we can make annevk's official title "Vishnu of Web Components" |
| 14:07 | <jgraham> | (it turns out that my Hindu mythology is weak) |
| 14:07 | <jgraham> | dglazkov is presumbably Brahma |
| 14:08 | <annevk> | "[Vishnu Sahasranama] describes Vishnu as the all-pervading essence of all beings, the master of—and beyond—the past, present and future, the creator and destroyer of all existences, one who supports, preserves, sustains and governs the universe and originates and develops all elements within." |
| 14:08 | <annevk> | Still o_O |
| 14:08 | <jgraham> | Heh |
| 14:08 | <MikeSmith> | annevk is vighneshvara the remover of obstacles |
| 14:08 | <annevk> | But I guess this is a welcome distraction from trying to figure out what the right resolution is for that bug |
| 14:08 | <jgraham> | Well I was thinking of it as "the creator, the preservor and the destroyer" |
| 14:09 | <jgraham> | So I am trying to pitch you in the role of the one who comes in and tidies up after the creators have made everything, but left a mess ;) |
| 14:23 | GPHemsley | has always wondered how to pronounce "Ms2ger"... |
| 14:24 | <Ms2ger> | There's no canonical pronunciation |
| 14:24 | <jgraham> | GPHemsley: First expand it to Msmsger |
| 14:27 | <GPHemsley> | Miss Messenger? |
| 14:27 | <jgraham> | He's actually former "Glamour Model" Melinda Messenger in disguise |
| 14:28 | <yoav> | zcorpan: Quick Q. I need a bunch of test cases for a tokenizer based on http://www.w3.org/TR/css3-syntax |
| 14:29 | <yoav> | Is there something like that in the test treasure trove that is https://github.com/operasoftware/presto-testo |
| 14:29 | <yoav> | ? |
| 14:29 | <zcorpan> | yoav: don't think so |
| 14:29 | <Ms2ger> | Dammit, cover blown |
| 14:30 | <Ms2ger> | SimonSapin might have some |
| 14:33 | <SimonSapin> | yoav: yes! |
| 14:33 | <SimonSapin> | https://github.com/SimonSapin/css-parsing-tests |
| 14:34 | <SimonSapin> | and the ED is more up-to-date: http://dev.w3.org/csswg/css-syntax/ |
| 14:35 | <yoav> | SimonSapin: Awesome!!! Thanks :) |
| 14:35 | <SimonSapin> | yoav: these tests are not suitable for a W3C test suit since the tokenizer is not exposed to the platform, but if you’re writing code in an implementation that’s not a problem |
| 14:37 | <SimonSapin> | you’ll need to write a test harness to convert whatever memory representation of tokens/component values you have to or from the tests’s JSON structure |
| 14:37 | <yoav> | SimonSapin: Yeah, I need them for unit testing, so it's perfect |
| 14:37 | <SimonSapin> | feel free to ping me or write a github issue |
| 14:53 | <Domenic_> | I always say "emm ess two gee-er" |
| 14:53 | <Domenic_> | (... in my head) |
| 15:02 | <GPHemsley> | yeah, that's roughly what I do |
| 15:02 | <GPHemsley> | the few times I've said it aloud, I generally provide multiple pronunciations |
| 15:07 | <zcorpan> | miss-two-ger, emm-ess-two-gee-er, miss-toger, em... es... two... gee... er. yep, him |
| 15:08 | <Ms2ger> | - Who? |
| 15:42 | <annevk> | cloneContents and extractContents are so similar |
| 17:11 | <dglazkov> | good morning, Whatwg! |
| 17:52 | <annevk> | dglazkov: objects already have an associated realm or global or whatever you want to call it |
| 17:52 | <annevk> | dglazkov: they need one |
| 17:54 | <dglazkov> | annevk: the realms are at the horizon of my peripheral vision, I just was coordinatin' :) |
| 17:55 | <dglazkov> | I was like, yay realms! and slightlyoff was like, ugh. I was like, wat! I must tell annevk! |
| 17:55 | <annevk> | hah |
| 17:55 | <dglazkov> | see? I am a coordinator! |
| 18:00 | slightlyoff | is so confused |
| 18:01 | <TabAtkins> | zcorpan: Ah, I don't have a way of inlining biblio extensions right now, so the API version won't work. |
| 18:02 | <TabAtkins> | zcorpan: What's the source you're using? I just changed my unicode handling, and am very interested in tracking down remaining bugs. |
| 18:23 | <annevk> | slightlyoff: blame dglazkov |
| 18:24 | <slightlyoff> | always do. always do. |
| 18:25 | <annevk> | Oh man, someone asked me to review the Beacon specification |
| 18:25 | <annevk> | Someone should seriously teach those guys how to write a specification, or maybe first code |
| 18:26 | <jgraham> | I hear that only takes a day |
| 18:26 | <annevk> | They asked: is it ready for LC? I replied: http://lists.w3.org/Archives/Public/public-web-perf/2014Feb/0048.html |
| 18:26 | <hober> | annevk: you could ask them to stay after class and write something 100 times on the board |
| 18:26 | <annevk> | I almost added, "So, for W3C's purposes this does indeed seem ready for LC." |
| 18:27 | <annevk> | But that would be mean, and the people I want to understand that sentiment would probably not get it either |
| 18:27 | <jgraham> | They would have taken you seriously |
| 18:27 | <jgraham> | (I am not being sarcastic) |
| 18:28 | <Ms2ger> | I can confirm that |
| 18:40 | <annevk> | hober: oh lol, TabAtkins actually said that o_O |
| 18:40 | <TabAtkins> | Hahaha |
| 18:41 | <annevk> | Doing Type 4 with sync accessors from the parent is going to be fun |
| 18:41 | <annevk> | I really wonder how people imagine something like <video> would work in such a setup |
| 18:51 | <TabAtkins> | If not full-on this-is-how-you-explain-crossorigin-iframes Type 4, you at least need something much stronger than anything that has been presented as an example of "Type 2". |
| 19:01 | <aklein> | anyone know what the right way to get someone to take a look at a web-platform-tests pull request is? maybe Ms2ger knows? |
| 19:01 | <Ms2ger> | aklein, ask me, I guess :) |
| 19:01 | <Ms2ger> | aklein, which? |
| 19:02 | <aklein> | Ms2ger: https://github.com/w3c/web-platform-tests/pull/624 brings the tests up to spec |
| 19:03 | <aklein> | ms2ger: er, the <template> tests |
| 19:03 | <Ms2ger> | Ah, shadow stuff |
| 19:03 | <Ms2ger> | I'll poke |
| 19:03 | <aklein> | not shadow related. or rather, <template> wormholes |
| 19:03 | <Ms2ger> | s/shadow/components/ |
| 19:03 | Ms2ger | lumps everything in together |
| 19:04 | <aklein> | heh, no, must decouple ALL the things! :) |
| 19:06 | <aklein> | Ms2ger: I'm especially interested in making sure that I've properly explained which spec change this is about |
| 19:12 | <Ms2ger> | aklein, I found a victim :) |
| 19:28 | <annevk> | TabAtkins: how then, btw, does Chrome use shadow DOM today to implement some stuff? |
| 19:28 | <TabAtkins> | Magic. |
| 19:29 | <TabAtkins> | Shadow DOM is an implementation detail there. |
| 19:30 | <Domenic_> | what extra magic is necessary? |
| 19:30 | <dglazkov> | the magic bit is that we have a nice C++/JS boundary that serves as trust boundary |
| 19:30 | <TabAtkins> | All the magic that blocks every leak of shadow access. |
| 19:30 | <Ms2ger> | Is that #2? |
| 19:31 | <TabAtkins> | Nope, at least not as ever defined in any way by Maciej or others. |
| 19:32 | <TabAtkins> | There are lots of data leaks, but only a few of them have ever been mentioned as part of "Type 2". |
| 19:32 | <TabAtkins> | It's *possible* that Maciej always meant "the kind of encapsulation that native elements get", but he's never expressed that, and if he does want that, it's a much bigger job. |
| 19:32 | <dglazkov> | well, to be fair -- it does have some of type 2 properties. But there's that trust boundary that actually does most of the work. |
| 19:41 | <jsbell> | Any AppCache experts/interested parties hereabouts? |
| 19:49 | <zcorpan> | TabAtkins: i used picture index.src.html but with s/Cáceres/Caceres/ |
| 20:14 | <TabAtkins> | zcorpan: Okay, let me check that out. |
| 21:03 | <SamB> | hmm, is there a standard that prescribes the behaviour of the "Refresh:" header? |
| 21:06 | <Hixie> | jsbell: i'm around if you have a question |
| 21:07 | <Hixie> | SamB: the header, or the <meta> pragma? |
| 21:07 | <SamB> | Hixie: well, this is in fact the header |
| 21:07 | <Hixie> | for the header i don't think there's a spec, but i could be wrong. See IETF. |
| 21:10 | <SamB> | So I guess if I said the meta tag, you'd have said "it's in HTML5" or "it's in HTML trunk"? |
| 21:11 | <Hixie> | the html standard defines how the pragma works, yeah. http://whatwg.org/html/#attr-meta-http-equiv-refresh |
| 21:11 | <jsbell> | Hixie: When an AppCache update fails we'd like to provide some sort of diagnostic that could be e.g. sent back to the server. Right now the "error" event is just an Event, so there's nowhere to stick the message. |
| 21:12 | <Hixie> | jsbell: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22702 |
| 21:13 | <Hixie> | jsbell: i'm kinda waiting to see what happens with service workers before i add anything to appcache, but if you and another vendor are ready to implement now, i can fast-track it |
| 21:15 | <SamB> | step 7 of that algorithm looks most unusual ... |
| 21:16 | <Hixie> | yeah... welcome to the web |
| 21:17 | <jsbell> | Hixie: a sensible stance; we have a real need to pursue this before SW is ready; can't speak for any other vendors, though. I can propose something in the bug. ISTM a semi-generic event type for errors w/ a place to stuff a name + message would be handy in the platform |
| 21:19 | <jsbell> | There's ErrorEvent already which has an error property (so, could hold a DOMError/DOMException/js Error); the source/line number fields aren't useful in this case, though. |
| 21:19 | <Hixie> | jsbell: if it's a generic string, we'll end up having to spec the exact strings, because authors are gonna do regexps on them |
| 21:19 | <Hixie> | jsbell: we'd create a new event, presumably (assuming we just use an event) |
| 21:20 | <Hixie> | jsbell: more information on exactly what the need is would be good to add to the bug |
| 21:20 | <SamB> | hmm, looks like Firefox does exactly the same thing with an actual Refresh header |
| 21:20 | <Hixie> | seems plausible |
| 21:57 | <SamB> | hmm, it would be cool if there was a "diff" view between the latest html5 "release" and html5 tip ... |
| 21:57 | <Hixie> | there is |
| 21:58 | <SamB> | yeah, I was just about to say "oh, it looks like there is" |
| 21:58 | <Hixie> | http://html5.org/tools/web-apps-tracker?from=8476&to=8477 is the diff between the "html tip" and the last thing we released |
| 21:58 | <Hixie> | http://html5.org/tools/web-apps-tracker for the home page |
| 21:58 | <SamB> | but wow is that overwhelming ... |
| 21:58 | <Hixie> | (s/last thing/previous thing/, i guess) |
| 21:59 | <SamB> | I'm not quite *that* pedantic |
| 21:59 | <Hixie> | uncheck "show editorial checkins" or whatever it's called |
| 21:59 | <Hixie> | it'll remove the minor stuff |
| 22:01 | <SamB> | hmm, mediawiki's diff-picking UI (with the radio buttons plus the "current" and "prev" links on each row) is better |
| 22:03 | <Hixie> | patches welcome :-) |
| 22:04 | <Hixie> | i _think_ the source is https://code.google.com/p/html5/source/browse/#svn%2Ftrunk%2Fweb-apps-tracker but it might have moved to github |
| 22:04 | <SamB> | yeah, I might have more hope of patching this than of building the spec (or was that validator.nu?) on OS X 10.5 ... |
| 22:04 | <SamB> | Hixie: see, this is why you should link to source for the webapp in question from the bottom of each page |
| 22:05 | <Hixie> | patches welcome for that too :-) |
| 22:05 | <Hixie> | i didn't write that |
| 22:05 | <Hixie> | that was mainly anne, i think |
| 22:05 | <Hixie> | ah, no, latest source is at https://github.com/whatwg/web-apps-tracker |
| 22:06 | <SamB> | and that patch would presumably be a great deal easier even than the diff-picking |
| 22:07 | SamB | wonders why he has an empty ~/hacking/whatwg directory ... |
| 22:07 | <Hixie> | check when you created it, then check irc logs for that day :-) |
| 22:08 | <SamB> | too late, I modified it now |
| 22:12 | <SamB> | Hixie: you seem to have assigned some rather unusual semantics to span ;-) |
| 22:12 | <Hixie> | hm? |
| 22:13 | <SamB> | in the spec sources I mean |
| 22:13 | <Hixie> | oh, for cross-references? |
| 22:13 | <Hixie> | yeah |
| 22:13 | <Hixie> | it gets all preprocessed and the <span>s go away in the output, mostly |
| 22:14 | <Hixie> | the source file isn't realy HTML |
| 22:14 | <Hixie> | it's HSML ("HTML Specification Markup Language") |
| 22:14 | <Hixie> | which is strongly influenced by HTML, certainly... |
| 22:14 | <SamB> | then why use an existing element name at all for that? |
| 22:14 | <Hixie> | inertia from a previous time where we used a different preprocessor |
| 22:15 | SamB | is reminded a bit of Lore, though that's not so un-HTML |
| 22:15 | <Hixie> | i'm slowly making myself a new pipeline that'll let me change all this to me much saer |
| 22:15 | <Hixie> | saner |
| 22:15 | <Hixie> | but it's one free-time project of many |
| 22:18 | <SamB> | <http://twistedmatrix.com/documents/current/lore/howto/lore.html>;, which I clicked through surprisingly many links to get to, gives a very clear idea of what lore does, I think |
| 22:19 | <Hixie> | yeah, there's lots of variants like this around |
| 22:19 | <Hixie> | even in the web spec world there's like half a dozen |
| 22:20 | <SamB> | I guess nowadays you could even do most/all of that in JS ... |
| 22:21 | <Hixie> | ideally a spec should be readably without JS, but yeah |
| 22:21 | <SamB> | I was thinking it might be handy for previewing, if it could be faithful to the other version |
| 22:22 | <SamB> | or I guess we have crazy things like node.js that might let us use the same thing for both |
| 22:22 | <Hixie> | to be honest, given the size of the html spec, the processing isn't likely to be very fast when it comes to previewing, JS or not |
| 22:22 | <Hixie> | (i rarely preview, heh) |
| 22:23 | <Hixie> | i realised the other day that the file i edit is literally 5% of the size of the first hard disk i had growing up |
| 22:23 | SamB | was also thinking aloud about what *lore* does, which is much less |
| 22:23 | <Hixie> | and wouldn't even remotely fit in the RAM of that computer, let alone earlier ones i used |
| 22:25 | <TabAtkins> | Nearly all specs are written as not-quite-HTML. |
| 22:25 | <TabAtkins> | And then passed through either Anolis or Bikeshed, or include the ReSpec js library for formatting client-side. |
| 22:26 | <TabAtkins> | Hixie just uses a really hacked-up version of Anolis. |
| 22:26 | <Hixie> | it's anolis, it just has some stuff in front and behind it |
| 22:27 | <TabAtkins> | ah, ok. |
| 22:27 | <TabAtkins> | Oh, and I forgot that SVG uses an XSLT thing as their formatter. |
| 22:27 | <TabAtkins> | With Dirk doing some of his fxtf specs by starting with the XSLT transformer and then passing through Bikeshed. |
| 22:28 | <Hixie> | there's also bert's old thing, dunno if anyone is using that any more, which was the tool that predated anolis |
| 22:28 | <TabAtkins> | A handful of CSS specs are still using it, but I've changed over at least half of the repo. |
| 22:28 | <TabAtkins> | Just converted another spec this afternoon. |
| 22:28 | <heycam> | TabAtkins, what? |
| 22:28 | <TabAtkins> | heycam: Don't you? |
| 22:28 | <heycam> | TabAtkins, oh that changed a while ago. it's pure JS now. |
| 22:28 | <heycam> | (a while = about a year ago) |
| 22:29 | <TabAtkins> | Oh, didn't realize! |
| 22:29 | <Hixie> | and that would make 6 :-) |
| 22:29 | <heycam> | Removing forceRedraw, suspendRedraw, unsuspendRedraw from SVG2 |
| 22:29 | <heycam> | er |
| 22:29 | <heycam> | https://svgwg.org/hg/svg2-tools/file/ee0a80076e9b/publish |
| 22:29 | <heycam> | Web IDL is still XSLT though ;) |
| 22:30 | <SamB> | ah, https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html is looking much nicer today. Thanks, TabAtkins and Hixie and whoever you needed help from! |
| 22:30 | <TabAtkins> | Ms2ger actually did it, and then I *also* did it without realizing he'd already done the work. |
| 22:30 | <SamB> | well, thanks to him too then ;-) |
| 22:30 | <TabAtkins> | Ugh, still doesn't have a max-width. |
| 22:31 | <TabAtkins> | max-width:50em or gtfo |
| 22:31 | <Hixie> | <crazy wolf>just increase your font size</crazy wolf> |
| 22:32 | <SamB> | speaking of max-width, I was trying to find a way to apply that to anonymous block-level boxes that hold inline-level boxes ... |
| 22:32 | <Hixie> | css really needs a way to address those |
| 22:32 | <SamB> | or something like that |
| 22:32 | <TabAtkins> | Hixie: Yes, we do. :/ |
| 22:32 | Hixie | has no idea how to do it, though |
| 22:32 | <Hixie> | i tried with the whoel move-to thing, but that sucks ass |
| 22:34 | <SamB> | so that I could make mediawiki stuff use a limited text width, without also cramming everything else into the same space, and so that indented blocks wouldn't have to be narrower necessarily |
| 22:35 | <SamB> | if you want to see what I *don't* want, try out the typography revamp beta on any of WMF's sites (wikipedia being the most popular) ;-) |
| 22:37 | <SamB> | Oh, have I mentioned my puzzlement as to why Selection needs to be bundled with *all* of those editing commands? |
| 22:37 | <Hixie> | the stuff in that spec is mostly the stuff aryeh worked on |
| 22:38 | <SamB> | so basically because Ranges died? |
| 22:38 | <Hixie> | really there should be one spec called "The Web Living Standard" |
| 22:38 | <Hixie> | but we've split it up for ease of editing |
| 22:38 | <Hixie> | so all the stuff I edit is in the HTML Standard, for instance |
| 22:38 | <Hixie> | Anne splits his parts up even more |
| 22:38 | <Hixie> | anyway, Range is in dom.spec.whatwg.org |
| 22:38 | <SamB> | not for ease of explaining piecemeal implementation? |
| 22:39 | <Hixie> | no, definitely not for that |
| 22:39 | <Hixie> | everything on the web is interconnected |
| 22:39 | <Hixie> | especially the old stuff |
| 22:39 | <Hixie> | like selection, dom, html, etc |
| 22:39 | <Hixie> | webidl, js... |
| 22:41 | <SamB> | true |
| 23:13 | <Hixie> | so... is there a spec that has a "must" for firing key-related events? |
| 23:20 | <jamesr__> | is there a spec that has even a "should" for firing key events? |
| 23:20 | <jamesr__> | afaik nobody even tries |
| 23:24 | <Hixie> | yeah, that's what i feared |
| 23:24 | <Hixie> | i'm speccing where the events should go, fwiw |
| 23:24 | <Hixie> | but not which ones they should be! |
| 23:34 | <TabAtkins> | Hixie: Any clue why <dfn>s can't be nested? |
| 23:34 | <Hixie> | what would it mean? |
| 23:34 | <TabAtkins> | ...two <dfn>s? |
| 23:34 | <TabAtkins> | I have an example of it in my spec, and the validator's flagging it. :/ |
| 23:34 | <Hixie> | paste the example here? |
| 23:35 | <Hixie> | it's invalid because i had never seen a use case for it and it seemed likely to be an unintentional mistake |
| 23:35 | <Hixie> | but if there's valid use cases, it can be valid |
| 23:35 | <TabAtkins> | http://dev.w3.org/csswg/css-font-loading/#dom-fontface-fontface |
| 23:35 | <Hixie> | (wouldn't it be really confusing to the user?) |
| 23:35 | Hixie | looks |
| 23:35 | <TabAtkins> | The Constructor function is <dfn>d, but so are the arguments to the function. |
| 23:36 | <Hixie> | why are the arguments <dfn>ed? that doesn't give the definition of the arguments |
| 23:36 | <Hixie> | that's very confusing |
| 23:37 | <Hixie> | with the multiple #-links showing up and all |
| 23:37 | <Hixie> | i can't tell what's actually being defined |
| 23:37 | <Hixie> | (as a side note, you have a method called Constructor()?) |
| 23:37 | <TabAtkins> | The arguments don't have an independent definition. That's the best place to put it. |
| 23:37 | <TabAtkins> | No, it's the constructor itself. |
| 23:37 | <Hixie> | i wouldn't bother <dfn>ing the arguments at all |
| 23:38 | <TabAtkins> | those are called Constructor in webidl. |
| 23:38 | <Hixie> | ah ok. s/method/constructor/ then probably |
| 23:38 | <TabAtkins> | That's cool, but Bikeshed's data model includes it, which lets me link directly to those arguments. |
| 23:38 | <TabAtkins> | And distinguish each use from other argumetns of the same name. |
| 23:38 | <Hixie> | (also, the constructor has a name (the interface name), so s/Constructor/whateveritsnameis/) |
| 23:39 | <TabAtkins> | All right, sure. |
| 23:39 | <Hixie> | i guess if i had to do this, i'd put the <dfn> for the constructor around its name, then put the arguments after it, much like i do in the domintro blocks |
| 23:40 | <Hixie> | as in, <code><dfn>MyFoo</dfn>(DOMString <dfn>arg</dfn>)</code> |
| 23:40 | <TabAtkins> | But why? |
| 23:40 | <Hixie> | that would make it clearer what the terms were |
| 23:40 | <TabAtkins> | If I don't have separatley-defined arguments, I'd definitely do <dfn>foo()</dfn> |
| 23:40 | <Hixie> | i mean, the constructor isn't called "Constructor(DOMString family)", it's called "Constructor" (or actually, "FontFace") |
| 23:41 | <TabAtkins> | That's a notation convention, not an absolute fact. |
| 23:41 | <Hixie> | (another side note, clicking FontFace in the IDL takes me to a 404) |
| 23:41 | <TabAtkins> | In prose, I usually write them as foo(). |
| 23:42 | <Hixie> | i agree |
| 23:42 | <TabAtkins> | Yeah, that 404 is temporary - I just moved some things. |
| 23:42 | <Hixie> | what i tend to do these days is actually not duplicate the arguments there |
| 23:42 | <Hixie> | i just leave them in the IDL and don't bother in the prose |
| 23:42 | <Hixie> | and i refer to them as foo() |
| 23:42 | <Hixie> | (methods and constructors) |
| 23:43 | <Hixie> | mostly i started doing that because it got really hard to write the prose with optional arguments and overloads and so on otherwise |
| 23:43 | <Hixie> | note that the argument names are arbitrary, which would be another reason <dfn> would be inappropriate for them |
| 23:43 | <Hixie> | since you're not really defining that term per se |
| 23:44 | <Hixie> | i mean, it's a "local" definition, i guess, for the sake of the following prose |
| 23:44 | <Hixie> | but to the reader it's a bit confusing to have a <dfn>-level definition for that, imho |
| 23:44 | <Hixie> | makes them seem more formally defined than they relaly are |
| 23:44 | <Hixie> | really |
| 23:45 | <TabAtkins> | Arguments do have defined names. |
| 23:45 | <TabAtkins> | You can't see that when calling, but that doesnt' change the fact that they're defined. |
| 23:46 | <TabAtkins> | One thing that might be confusing you is that your publishing pipeline only has global definitions. |
| 23:47 | <TabAtkins> | Bikeshed's definition data model has nesting relationships - this is defining the "family" argument for the "FontFace()" method of the "FontFace" interface. |
| 23:48 | <Hixie> | i'm not confused :-) |
| 23:48 | <Hixie> | argument names to IDL-defined methods and constructors are arbitrary, they're just a spec editing help |
| 23:48 | <Hixie> | you could name them all arg1, arg2, arg3, etc and it wouldn't change anything normatively detectable |
| 23:48 | <Hixie> | s/normatively/black-box/ |
| 23:49 | <TabAtkins> | They're 'arbitrary' in the same sense that every term in every spec is arbitrary. |
| 23:49 | <Hixie> | right |
| 23:49 | <Hixie> | as opposed to the method name, which isn't arbitrary, say |
| 23:49 | <Hixie> | anyway that's a side issue |
| 23:49 | <TabAtkins> | Exactly. ^_^ |
| 23:50 | <Hixie> | as far as <dfn> goes, the point is just that it's confusing to users to have nested <dfn>s. to put it as you might put it: "one thing that might be confusing you is that bikeshed's data model has nesting relationships" |
| 23:50 | <Hixie> | whereas people don't tend to think that way |
| 23:50 | <TabAtkins> | ...yes they do. |
| 23:50 | <TabAtkins> | A given "auto" value belongs to a particular property. |
| 23:50 | <TabAtkins> | That's nesting. |
| 23:51 | <TabAtkins> | There are like 30 different definitions (or more) of "auto" in CSS. |
| 23:51 | <Hixie> | it's a hierarchy, sure |
| 23:51 | <Hixie> | "nesting" implies more than hierarchy though |
| 23:51 | <Hixie> | it implies scoping |
| 23:51 | <TabAtkins> | I'm implying hiearchy. |
| 23:51 | <TabAtkins> | ...never mind. Let's not have random semantic debates, because they aren't winnable by either side. |
| 23:52 | <Hixie> | k |
| 23:52 | <TabAtkins> | Back to the question - I provided a valid use of nested definition. |
| 23:52 | <TabAtkins> | nested <dfn>s, rather. |
| 23:52 | <Hixie> | whether it's valid or not depends entirely on the semantic debate we were having |
| 23:52 | <Hixie> | imho it's not valid, it's obviously confusing to the reader and is semantically wrong in that the term you're defining doesn't include the other term. |
| 23:53 | <Hixie> | and, the other term probably shouldn't be <dfn>-defined anyway because it's arbitrary and local to that algorithm. |
| 23:53 | <TabAtkins> | Only if you're inferring something weird. A <dfn> is just a <dfn>. The fact that, in this case, the inner definitions are nested in the outer definition, mirroring the markup structure, is irrelevant. |
| 23:54 | <TabAtkins> | The inner <dfn>s don't change meaning just because there's another <dfn> wrapped around them. The outer <dfn> treats every other inline contained within it neutrally; there doesn't seem to be any reason why it should treat a contained <dfn> differently |
| 23:55 | <Hixie> | i do not disagree with what you are saying, but what you're saying is orthogonal to the problems i described. |
| 23:55 | <TabAtkins> | You're using "arbitrary" as a synonym for "not web-exposed". That's not a useful definition when we're discussing spec definition models. |
| 23:55 | <Hixie> | no, i mean "arbitrary" as in "the name doesn't matter" |
| 23:55 | <TabAtkins> | Yes, but saying "this definition is arbitrary, thus it shouldn't be <dfn>'d" is wrong. |
| 23:56 | <TabAtkins> | Important terms in specs are <dfn>'d all the time. |
| 23:56 | <TabAtkins> | If you're just saying that you don't think *method arguments* are sufficiently useful to justify <dfn>ing, that's a cool opinion, but I differ in it. |
| 23:57 | <TabAtkins> | And it's irrelevant here. |
| 23:57 | <Hixie> | i think i could be convinced that <dfn>-defining arguments to algorithms before the algorithm is defensible, but if one did do that, i do not think doing it via nested <dfn> would be a good way to do it. |
| 23:58 | <TabAtkins> | In many cases you wouldn't. In a case like what I'm showing you, you do, because that's the syntactic convention I've adopted for defining methods. |
| 23:58 | <Hixie> | sure. we're debating the relative worthiness of that convention. |
| 23:59 | <TabAtkins> | Well, we're debating whether it's sufficiently incorrect as to be worth making *invalid*. |
| 23:59 | <Hixie> | right, i'm arguing it's confusing to the reader, semantically dubious since the names involved aren't really the ones you're marking up, and doesn't justify making validators no longer flag (likely accidentally) nested <dfn>s |