| 01:27 | <gsnedders> | Hixie_, TabAtkins: So I'm kicking about San Jose with nothing to do Sep 3/4. Am wondering about popping up in the middle of your domain and sitting around in the café all day and trying to see as many of you Google people as possible. |
| 01:28 | <Hixie_> | if you want to maximise your seeing people, your best bet is to sit on the shoreline/101 bridge and watch the freeway and shoreline during rush hour |
| 01:29 | <Hixie_> | happy to do lunch or something though either of those days |
| 01:29 | <gsnedders> | Hixie_: Pedant. :) |
| 01:31 | <gsnedders> | Also, while you're here, I seem to have agreed to do a bachelor's thesis on model checking the HTML parser. At least initially aiming for stuff like "(fragment case.)" genuinely only being fragment case. |
| 01:31 | <gsnedders> | May try, if it goes well, and prove termination. |
| 01:35 | <Hixie_> | if you manage to prove that in a script-capable browser, you'll have earnt a nobel prize. or would have, if they did math ones. |
| 01:36 | <gsnedders> | Well, yes. But it's trivial to prove that in the script-enabled case it may never terminate. |
| 01:36 | <Hixie_> | note that i may drop the "fragment case" stuff, due to it being so inconsistently done |
| 01:41 | <gsnedders> | Eh, at least what's currently in the spec is a starting point. |
| 01:58 | <gsnedders> | Hixie_: Equally, if there's anything you think that'd be useful, say! |
| 02:04 | <gsnedders> | Basic plan is fragment case, no popping from an empty stack, that foreign content/not insertion modes are only used when appropriate, and that there are no unhandled tokens. |
| 02:04 | <gsnedders> | In no particular order. |
| 02:16 | <Hixie_> | gsnedders: not really sure what would be useful, but we can talk about it at lunch :-) |
| 02:25 | <GPHemsley> | Hixie_: "anticlockwise" is not en-US |
| 02:26 | <Hixie_> | witness my horror |
| 02:26 | <GPHemsley> | easy now |
| 02:26 | <GPHemsley> | don't overexert yourself |
| 02:27 | <Hixie_> | :-) |
| 02:28 | <GPHemsley> | FTR, the en-US equivalent is "counterclockwise" |
| 02:28 | <Hixie_> | yeah, i know |
| 02:29 | <Hixie_> | not sure if it was my fault or not that the spec uses anticlockwise |
| 02:29 | <Hixie_> | could be apple's fault though |
| 02:29 | <Hixie_> | since i think arc() dates back to their canvas doc |
| 02:29 | <GPHemsley> | ah, ok |
| 02:29 | <GPHemsley> | I'd much prefer to blame Apple ;) |
| 02:29 | <Hixie_> | either way, i'm happy to ignore it :-) |
| 02:29 | <GPHemsley> | though I suppose that means you can't change it |
| 02:30 | <Hixie_> | it's an argument, i don't think it has any normative value actually |
| 02:30 | GPHemsley | shrugs |
| 02:30 | <Hixie_> | (argument name, that is) |
| 02:30 | <GPHemsley> | just doing my job as the en-US police ;) |
| 02:32 | <Hixie_> | i miss the days where the spec was en-GB |
| 02:32 | <Hixie_> | before the w3c got involved |
| 02:32 | <Hixie_> | it strikes me i could change it back... |
| 02:33 | <GPHemsley> | heh |
| 06:56 | <zcorpan> | how should we represent the margin at-rules in @page in CSSOM? a common interface for all of them and a property that exposes the name? or one interface each? |
| 06:57 | <zcorpan> | http://dev.w3.org/csswg/css-page/#margin-boxes - there are 16 of them |
| 07:13 | <zcorpan> | i'm tempted to go with a common interface but i don't know what to call the property that exposes the name. hmm, maybe just "name" might work |
| 07:13 | <zcorpan> | selectorText seems wrong |
| 07:13 | <zcorpan> | maybe i should have "name" on all rules |
| 07:15 | <zcorpan> | or all at-rules |
| 07:24 | <hsivonen> | Hixie_: I think http://www.w3.org/TR/charmod-norm/ makes sense, but the group that wrote the doc has disowned it |
| 07:25 | <hsivonen> | the validator implements it anyway |
| 07:25 | <hsivonen> | so in that sense "we" "require" NFC |
| 07:27 | <hsivonen> | Hixie_: the ban on combining character as the first character of a text node comes from http://www.w3.org/TR/charmod-norm/#sec-FullyNormalized |
| 07:28 | <zcorpan> | hsivonen: maybe we should put the necessary requirements in the html spec? |
| 07:29 | <hsivonen> | zcorpan: perhaps it would be good to find out what the i18n group thinks is wrong with charmod-norm first |
| 07:30 | <hsivonen> | anyway, as a pratical matter, stuff breaks in some UAs if you don't have each text node in NFC and not starting with a combining char |
| 07:31 | <zcorpan> | isn't it better long-term to fix the UAs to not break? |
| 07:33 | <hsivonen> | zcorpan: considering effort vs. use case payoff, maybe not |
| 07:34 | <hsivonen> | dunno. roc or jfkthame would be better positioned to say |
| 07:34 | hsivonen | finds http://annevankesteren.nl/2003/07/updates-follow interesting |
| 07:35 | <hsivonen> | I used to believe in XML, too, but not in XML Schema |
| 07:49 | <SimonSapin> | zcorpan: http://lists.w3.org/Archives/Public/www-style/2013May/0777.html |
| 07:50 | <SimonSapin> | re page-margin rules |
| 07:50 | <zcorpan> | SimonSapin: thanks |
| 07:51 | <zcorpan> | SimonSapin: any opinion on whether we should expose .name on all at-rules? |
| 07:51 | <SimonSapin> | zcorpan: but I was just thinking it could also work to *not* make it a grouping rules and just have 16 accessors on CSSPageRule |
| 07:52 | <SimonSapin> | zcorpan: .name would be redundant with .type, except in special cases like this one |
| 07:53 | <zcorpan> | with .type you have to have your own mapping if you actually want the name |
| 07:53 | <SimonSapin> | 16 accessors would expose a partial result of the cascade rather than really the structure of the stylesheet, but we already do that for CSSStyleDeclaration anyway… |
| 07:54 | <SimonSapin> | well, do you want the name? |
| 07:54 | <zcorpan> | dunno :-) |
| 07:55 | <SimonSapin> | let’s not add it before anyone asks for it |
| 07:55 | <zcorpan> | i'm not sure i like the accessors thing. it might get ugly if it gets extended with a bazillion new things |
| 07:55 | <zcorpan> | like we considered accessors for @page but then realized there were lots of properties that apply now |
| 07:56 | <zcorpan> | so i think using .cssRules and .style is better even if there are currently just a "few" things |
| 07:56 | <SimonSapin> | yeah, declarations in @page are really more like a style rule, I agree with using .style |
| 07:57 | <zcorpan> | it also means developers don't have to look it up each time if the stuff is exposed as accessors or cssRules/style if we're consistent |
| 07:57 | <SimonSapin> | but I don’t see css-page being extended to have 128 pre-defined margin boxes, that’s just not a good design |
| 07:58 | <SimonSapin> | rather, I expect css-page-4 to take a new direction |
| 07:58 | <zcorpan> | might not be margin boxes |
| 07:58 | <zcorpan> | might be other at-rules for something we haven't thought of yet |
| 07:58 | <zcorpan> | anyway |
| 07:58 | <SimonSapin> | oh you’re right, you’d still have at-rules in @page, then .cssRules makes sense |
| 07:59 | <zcorpan> | ok i'm just exposing .name on margin rules |
| 08:00 | <zcorpan> | i'll also use the constant 9 |
| 08:02 | <SimonSapin> | I don’t know what "reserved constant" really means |
| 08:06 | <zcorpan> | i think it just means it's not allocated yet and it's not allowed to be used for vendor-specific stuff |
| 08:06 | <SimonSapin> | ok |
| 08:06 | <SimonSapin> | I’s say mention it on www-style, but it should be fine |
| 08:06 | <zcorpan> | yeah |
| 08:35 | <zcorpan> | so, next thing to consider is whether we should update CSSFontFaceRule to use this approach also |
| 08:36 | <zcorpan> | i guess i'll send an email about that |
| 08:36 | <zcorpan> | or maybe i should wait a bit |
| 08:36 | <SimonSapin> | which approach? |
| 08:37 | <zcorpan> | http://lists.w3.org/Archives/Public/www-style/2013Jun/0668.html |
| 08:38 | <SimonSapin> | I’m less sure about that |
| 08:39 | <SimonSapin> | @page really contains properties, but not @font-face |
| 08:43 | <SimonSapin> | and CSSFontFaceRule might be harder to change if it’s already shipped |
| 08:43 | <zcorpan> | @font-face contains descriptors. pretty similar. the CSSDeclaration machinery makes sense for descriptors also afaict |
| 08:43 | <zcorpan> | it's not shipped |
| 08:44 | <zcorpan> | or .style with CSSStyleDeclaration is shipped, i.e. the old definition, which doesn't make sense for @font-face |
| 08:44 | <zcorpan> | but .style with CSSFontFaceDescriptors (or Declaration) would make sense |
| 08:46 | <zcorpan> | but i'll wait for feedback on the @page thing before opening the @font-face can on the list, i think |
| 08:48 | <SimonSapin> | I don’t think CSSStyleDeclaration is a good model that we should reproduce |
| 08:50 | <SimonSapin> | It’s halfway between an AST (which would be an ordered list with duplicates) and the results of the cascade (an unordered map) |
| 08:51 | <zcorpan> | well if you think we should use a third approach instead, please propose it on the list :-) |
| 09:03 | <MikeSmith> | hsivonen: so this week I learned that the ARIA spec permits the value of the role attribute to be a space-separated list of tokens, and that role="foo dialog" is supposed to be handled as valid, as far as document conformance -- if at least one token in the list is the name of a non-abstract role defined in the ARIA 1.0 spec (and as far as HTML validation goes, if that role value is actually allowed for the element the role attribute is used with) |
| 09:04 | <MikeSmith> | the requirement seems to be that the first valid abstract role name found in the list is the role value that should be used, and the rest of the tokens are ignored |
| 09:07 | <MikeSmith> | so anyway, the only practical way I can think of to implement support for this in the validator is to add a filter that examines the role values and changes them into single role names before the document is checked against any schema by jing |
| 09:07 | <MikeSmith> | similar to the way that data-* attributes are handled |
| 09:08 | <MikeSmith> | so that's what I'm implementing right now |
| 09:08 | <MikeSmith> | but if you think that's a bad idea, let me know |
| 09:12 | <MikeSmith> | I already sent a comment to the PFWG saying that what they should do instead is not have the multiple-token-role-value mechanism at all, and require that the value contain only a single role name, but I would guess that they're not likely to ever actually agree to that |
| 09:23 | <smartgloves> | sup |
| 09:49 | <zcorpan> | MikeSmith: iirc hsivonen commented on the document conformance rules when they were made up that it doesn't make sense to allow in for document conformance until the ARIA 2.0 bridge is crossed |
| 09:50 | <zcorpan> | MikeSmith: which i tend to agree with |
| 09:51 | <zcorpan> | MikeSmith: i made up the rules back in 2006 to convince the group to go with that extensibility model instead of something more insane that was in place before it (don't remember what it was) |
| 09:51 | <zcorpan> | or 2007 or whenever |
| 09:53 | <jgraham> | TabAtkins: Well .flatMap is still quite ugly — although I grant that .bind isn't much better — and, unless I have totally failed to follow something is very confusing for promises since it does less flattening than the .then method. That seems like a road to confusion. |
| 09:53 | <zcorpan> | MikeSmith: the UA processing makes sense and allows for future extensions |
| 10:02 | <MikeSmith> | zcorpan: yeah I can understand how it makes sense for UA processing |
| 10:02 | <MikeSmith> | zcorpan: but wait you're saying you're the one who originally proposed this design? |
| 10:02 | <zcorpan> | MikeSmith: yes |
| 10:02 | <MikeSmith> | ok |
| 10:03 | <MikeSmith> | well that makes it seem slightly less bad to me |
| 10:03 | <zcorpan> | http://simon.html5.org/specs/aria-proposal |
| 10:04 | <MikeSmith> | by itself it's not really a design that's bad for validation purposes |
| 10:04 | <hsivonen> | MikeSmith: ignoring unknown tokens makes sense for UA processing model but not for validation, IMO |
| 10:04 | MikeSmith | reads |
| 10:04 | <hsivonen> | MikeSmith: if it made sense for validation, we'd make all unknown attribute names valid, too |
| 10:04 | <MikeSmith> | hsivonen: I can have the filter emit an error for each unknown token |
| 10:05 | <hsivonen> | MikeSmith: OK |
| 10:05 | MikeSmith | reads zcorpan proposal |
| 10:06 | <MikeSmith> | the real problem for ARIA validation is the massive baroqueness of the requirements for which aria-* states and properties can be used with which roles, and then which roles can be used with which HTML elements |
| 10:07 | <zcorpan> | MikeSmith: giving errors for unknown tokens is basically a more complicated way to just check the whole value as one token, since it makes little sense to provide several known tokens |
| 10:07 | hsivonen | sees "CURIE" in zcorpan's doc |
| 10:08 | <MikeSmith> | zcorpan: yeah I suppose that's true |
| 10:09 | <zcorpan> | hsivonen: yeah, i guess i had to bend over backwards to please the XML-drinking accessibility guys :-) |
| 10:09 | <MikeSmith> | heh |
| 10:09 | <hsivonen> | I thought XML was smoked rather than drunk |
| 10:11 | <zcorpan> | maybe so. what's being drunk? |
| 10:11 | <hsivonen> | kool aid |
| 10:11 | <hsivonen> | so I suppose XML can be both smoked and drunk |
| 10:12 | <hsivonen> | it's a floor wax and a dessert topping |
| 10:13 | <jgraham> | Oh, I thought XML kool aid was administered in an enema |
| 10:15 | <zcorpan> | it goes in from all directions, and goes out through the ears? |
| 10:18 | <zcorpan> | MikeSmith: my proposal has an issue "What authors are allowed to do should probably be constrained" |
| 10:19 | <MikeSmith> | zcorpan: about checking the whole value as one token, I suppose so, except that if the value has at least one token that's a known role name, then I can pass on that value to the rest of the validation pipeline for further checking, while dropping all the rest |
| 10:20 | <MikeSmith> | maybe the error message should explicitly say, "Dropping invalid token "foo" from role value." |
| 10:20 | <zcorpan> | MikeSmith: true |
| 10:21 | <zcorpan> | yeah |
| 10:22 | <MikeSmith> | ok, I can implement it that way for now and tweak it later if needed |
| 10:22 | <zcorpan> | jgraham: did you look on the filelist review issue? |
| 10:23 | <jgraham> | zcorpan: No, but I can do it now (or in a few minutes) |
| 10:23 | <jgraham> | If you have the review open can you paste the link? |
| 10:24 | <zcorpan> | https://critic.hoppipolla.co.uk/r/238 |
| 10:49 | <jgraham> | zcorpan: OK, tracking is restored |
| 10:49 | <jgraham> | Unfortunately it seems all the changes ended up in a merge commit from critic's point of view |
| 10:49 | <zcorpan> | jgraham: thanks! |
| 10:49 | <zcorpan> | good enough |
| 11:33 | <zcorpan> | sigh htmlwg has a gazillion components |
| 11:34 | <zcorpan> | maybe i should just pick one at random |
| 11:38 | <Ms2ger> | File in WHATWG instead? :) |
| 11:42 | <zcorpan> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23002#c7 |
| 11:43 | <zcorpan> | hsivonen: do you have an opinion on the above bug? |
| 11:46 | <hsivonen> | zcorpan: I don't care much either way, but it's weird not to be consistent with <script>. might be good to check with wchen. |
| 11:48 | <zcorpan> | seems unlikely anyone will have a strong opinion on this :-P |
| 11:49 | <jgraham> | I think "just do it" is the right approach. It doesn't seem like it should need explicit buy in from lots of people since it's such a small thing |
| 11:49 | <zcorpan> | yeah |
| 11:50 | <zcorpan> | commented |
| 12:33 | <odinho> | OH MY. I really hate hate hate that NodeList and all the other stupid *List's don't have Array in their prototype chain! GRRR. |
| 12:34 | <odinho> | It makes programming so frustrating. Those small cuts. I can't do document.querySelectorAll('bla').forEach(function() { this.bla }) |
| 12:35 | <Ms2ger> | Push for Chromium to ship it again? :) |
| 12:36 | <odinho> | <3 |
| 12:40 | <wilhelm> | Yes, please. |
| 12:40 | wilhelm | needed that.. yesterday. |
| 14:23 | <jgraham> | zcorpan: You also need to mark the "conflicts" part in that review |
| 14:24 | <zcorpan> | jgraham: yeah i noticed |
| 14:24 | <jgraham> | I think it is the same as the diff against parent 1, so should just be mechanical (in this case) |
| 14:25 | <jgraham> | Nice! |
| 14:25 | <zcorpan> | ok should i close and merge also? |
| 14:26 | <jgraham> | I beat you to it |
| 14:26 | <zcorpan> | ah, thanks |
| 14:27 | <jgraham> | Although I am not happy |
| 14:27 | <jgraham> | I think I need to fix things up |
| 14:35 | <annevk> | Is media fragments implemented? How does it work with XMLHttpRequest and drawImage()? |
| 14:35 | <jgraham> | OK, I don't know how to fix things up |
| 14:42 | <zcorpan> | jgraham: :-( what's the problem? |
| 14:46 | <jgraham> | zcorpan: Well nothing serious enough to actually worry about, I think |
| 14:47 | <jgraham> | The author did something like merged their branch with some other non-master branch, or rebased master on top of their branch, or something, that had the net effect of adding commits that were already in master but with different SHA1s |
| 15:00 | <zcorpan> | jgraham: please point out to belem that he messed up and say what he should do instead in the future |
| 15:00 | <jgraham> | zcorpan: Already on it :) |
| 15:01 | <zcorpan> | k :-) |
| 15:24 | <annevk> | http://www.w3.org/TR/media-frags/#processing-media-fragment-uri :/ |
| 15:24 | <annevk> | Is that implemented? |
| 15:24 | <annevk> | "If either name or value are not valid UTF-8 strings, then remove the name-value pair from the list." ... |
| 15:27 | <annevk> | <!DOCTYPE html><img src=image#xywh=0,0,40,40> |
| 15:27 | <annevk> | Should that work? |
| 15:27 | <annevk> | Because it doesn't |
| 15:32 | annevk | asks in https://bugzilla.mozilla.org/show_bug.cgi?id=790640 |
| 15:37 | <matjas> | MikeSmith: would you mind enabling the issue tracker on https://bitbucket.org/validator/validator/src since http://bugzilla.validator.nu/ has been down for a few weeks now? |
| 15:47 | <Ms2ger> | annevk, http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsMediaFragmentURIParser.h#15 |
| 15:48 | <annevk> | Ms2ger: how does the temporal stuff work? |
| 15:48 | <Ms2ger> | No idea |
| 15:48 | <Ms2ger> | matjas, seems up |
| 15:49 | <TabAtkins> | gsnedders: that sounds good - I'm free that week. |
| 15:50 | <annevk> | Seems the specification doesn't detail much at all. Man... |
| 15:51 | <annevk> | How can you write that much text with a group of people and not consider the basic processing model? |
| 15:51 | <TabAtkins> | zcorpan: While I support adding a property to rules that contains their name, I currently have CSSCounterRule specced to have a name attribute. |
| 15:51 | <TabAtkins> | zcorpan: Though, I suppose we're switching to a consistent .style for that. |
| 15:55 | <matjas> | Ms2ger: I just get timeouts, like 90% of the time |
| 15:55 | <Ms2ger> | matjas, mm, I loaded once and it seemed to appear |
| 16:13 | <gsnedders> | annevk: AFAIK it's only really implemented for video/audio |
| 16:18 | <annevk> | Thinking about it some more, https://gist.github.com/annevk/6295844 could probably make use of the same syntax as media resources. We'd just claim "path="... |
| 17:20 | <TabAtkins> | annevk: Yeah, I think we need to spec that "foo=..." in the hash is reserved. |
| 17:23 | <TabAtkins> | So, I want Bikeshed to automatically add ids to issues in the spec (and a permalink icon, like headings now get), so they're easy to link to. But I also want the ids to be stable across modifications elsewhere in the draft. |
| 17:23 | <TabAtkins> | I'm thinking of just hashing the textContent of the issue and using that in the id. Thoughts? |
| 17:25 | <jgraham> | Hashing works great if you are a machine and/or misathropist |
| 17:25 | <jgraham> | +n |
| 17:25 | <TabAtkins> | No one's trying to guess the ids, just link to them. |
| 17:25 | <jgraham> | Yes, but it makes them impossible to understand or remember |
| 17:25 | <TabAtkins> | Also: anyone got a suggestion for a hash algo that's (a) standard in Python, and (b) generates a short output string? |
| 17:26 | <TabAtkins> | jgraham: Yeah, but the understandable auto-genned ones aren't stable. |
| 17:26 | <TabAtkins> | You can always add an id yourself. |
| 17:26 | <jgraham> | hashlib.sha1(text).hexdigest()[:8] |
| 17:27 | <TabAtkins> | Sure. And I already have dedup functionality, so I dont' need to worry about collisions. |
| 17:29 | <SimonSapin> | TabAtkins: so the id changes as soon as you reword / change anything in the issue? |
| 17:30 | <TabAtkins> | SimonSapin: Yes. They're stable against changes *elsewhere* in the doc, but not to changes within the issue. Better suggestions are welcome. |
| 17:30 | <SimonSapin> | yell at editors that don’t specify IDs? ;) |
| 17:31 | <TabAtkins> | I'm already adding a warning when you don't specify an id for the heading. |
| 17:31 | <TabAtkins> | Maybe I could autogen the id, but also warn? |
| 17:31 | <TabAtkins> | But coming up with issue ids is annoying. :/ |
| 17:35 | <SimonSapin> | TabAtkins: parsed declarations in a stylesheet have cascaded values, which are intial, inherit, unset or a specified value. Does that sound right? |
| 17:35 | <weinig> | TabAtkins: you don't happen to know if there are any tests for the DOM spec Promises stuff do you? |
| 17:36 | <TabAtkins> | weinig: Ask annevk |
| 17:36 | <weinig> | he no here :( |
| 17:36 | <weinig> | TabAtkins: I'll give him an email |
| 17:36 | <TabAtkins> | SimonSapin: No, they have declared value. Cascaded values are the result of the cascade, and belong to element/property combos. |
| 17:36 | <TabAtkins> | http://dev.w3.org/csswg/css-cascade/#value-stages |
| 17:37 | <SimonSapin> | so how do I call a declared value that is not a CSS-wide keyword? |
| 17:38 | <TabAtkins> | What's your need? |
| 17:38 | <SimonSapin> | in Servo’s style system, the value of each CSS property is represented by a different data type |
| 17:39 | <SimonSapin> | I don’t want to deal with initial/inherit/unset in each of them, but make it generic |
| 17:39 | <TabAtkins> | Yeah. |
| 17:39 | <SimonSapin> | So I have a type like this: enum DeclaredValue<T> { Initial, Inherit, Unset, XXXValue(T) } |
| 17:39 | <SimonSapin> | Rust enums are what C calls tagged unions |
| 17:40 | <SimonSapin> | I’m looking for a name for XXXValue |
| 17:40 | <TabAtkins> | When we need to distinguish in specs, we just say "not a global keyword" or something and link to the section in Values or Cascade. :/ |
| 17:41 | <SimonSapin> | isn’t that "specified value"? |
| 17:41 | <TabAtkins> | Nope, specified value is the cascaded value after resolving the global keywords away. |
| 17:41 | <SimonSapin> | in terms of what the possible, well, values, are. |
| 17:41 | <TabAtkins> | It's not a name for a class of values, but rather a part of the value computation stage. |
| 17:42 | <TabAtkins> | But sure, you could use it for that. |
| 17:42 | <TabAtkins> | It wouldn't be ambiguous. |
| 17:42 | <TabAtkins> | And, hm, I guess we do use the words like that in specs. So yes. |
| 17:42 | <SimonSapin> | I see |
| 17:42 | <jgraham> | weinig: If there are any I haven't seen them |
| 17:42 | <SimonSapin> | that stage of the cascade will also use the same type |
| 17:43 | <jgraham> | weinig: But it is possible that someone didn't get the memo and wrote implentation-specific tests |
| 17:43 | <SimonSapin> | close enough I guess |
| 17:45 | <TabAtkins> | SimonSapin: Yeah, now that I think about it, we do use the term to mean the set of values that exist in that stage. |
| 17:45 | <TabAtkins> | So it's valid to use SpecifiedValue(T) in that enum. |
| 17:46 | <jgraham> | weinig: http://dxr.mozilla.org/mozilla-central/source/dom/promise/tests |
| 17:50 | <weinig> | jgraham: thanks! |
| 19:29 | <zcorpan> | Hixie_: switching the spec to en-GB seems like it would give the html wg editors more grief :-P |
| 19:31 | Ms2ger | had been wondering if that was part of the motivation |
| 19:33 | <Hixie_> | no, the motivation would be my sanity. i go crazy trying to remember what's american and what's british and keep getting it wrong. |
| 19:34 | <Hixie_> | to be honest i don't pay much attention to downstream use by the htmlwg, since the _entire point_ of my not editing that spec any more was that editing that spec was too much work |
| 19:34 | <Hixie_> | because of exactly this kind of thing |
| 19:35 | <Hixie_> | so if i thought it was worth my time to worry abotu that, i wouldn't have stopped editing that spec :-) |
| 20:25 | <zcorpan> | ok i think i'm done with https://bugzilla.mozilla.org/show_bug.cgi?id=725646 now |
| 20:27 | <zcorpan> | Ms2ger: was there a bug about dropping it from the spec? |
| 20:27 | <esprehn> | Hixie_: when should an autofocus element become focused wrt the onload event firing? |
| 20:27 | <Ms2ger> | zcorpan, I don't recall |
| 20:28 | <Ms2ger> | zcorpan, does the spec have it? |
| 20:28 | <zcorpan> | yep |
| 20:28 | <zcorpan> | i'll file one |
| 20:28 | <Ms2ger> | Okay, thanks |
| 20:28 | <esprehn> | Hixie_: the spec says to "Queue a task that checks to see if the element is focusable," when the element is inserted, but I don't see any ordering requirement for onload |
| 20:58 | <zcorpan> | TabAtkins: Counter Styles -- my brain first read that as Counter Strike |
| 21:01 | <TabAtkins> | zcorpan: That's basically what it is. |
| 21:02 | <zcorpan> | TabAtkins: it would be a fun easter egg to embed the game in the spec |
| 21:02 | <TabAtkins> | Probably detectable in the load time. |
| 21:03 | <zcorpan> | you can delay loading it until some gesture is made |
| 21:12 | <TabAtkins> | I presume it's already been enscriptened? |
| 21:20 | <zcorpan> | no idea |
| 21:20 | <zcorpan> | haven't seen it in a browser |
| 21:46 | <MikeSmith> | matjas: I've enabled the gh issue tracker for https://bitbucket.org/validator/validator/src so feel free to use it if that works better for you but if http://bugzilla.validator.nu/ availability contintues to be a problem I'd personaly prefer you use https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Validator%20(Nu) as an alternative instead of the gh issue tracker |
| 21:47 | <MikeSmith> | s/gh/bitbucket/ |
| 21:50 | <MikeSmith> | anyway, among other reasons why I'd suggest https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Validator%20(Nu) as a better alternative is that the since the validator sources are in 7 different bitbucket repos, using bitbucket for issue tracking would mean enabling the issue-tracking feature in multiple other repos there |
| 21:50 | <MikeSmith> | e.g., https://bitbucket.org/validator/syntax/src |
| 21:53 | <jwalden> | Hixie_: I am a little behind on scrollback ;-) but in the very unlikely chance you never found a better possibility, "is informed by" or (with less control/authority connotation) "is aware of" might work for the A-B non-symmetric relationship phrase you were looking for |
| 21:54 | <TabAtkins> | zcorpan: On more thought, I'm not sure I'm comfortable with the @page OM change. I'm fine with the idea of it, but we really need a model that reflects the relative ordering of at-rules and declarations. It's not relevant for @page, but it will be in the future for style rules if we do @mixin or something. |
| 21:55 | <TabAtkins> | zcorpan: So it may be worthwhile to actually innovate here, and design something that can be copied over to style rules later. |
| 22:09 | <zcorpan> | TabAtkins: why do we need the order for @mixin? |
| 22:10 | <TabAtkins> | Because @mixin is basically a variable holding declarations, so it matters whether *other* declarations appeared before or after it. |
| 22:11 | <gsnedders> | Woah. What's happened to Bugzilla!? |
| 22:14 | <zcorpan> | TabAtkins: ok. sleep time now. take it on the list :-) |
| 23:34 | <Hixie_> | esprehn: is it the same task source as the load event? |
| 23:34 | <Hixie_> | jwalden: wow, that _is_ behind on scrollback. :-P We went with "is familiar with" for now. |
| 23:36 | <jwalden> | :-) |