| 09:02 | <annevk> | Whoa whoa whoa http://lists.w3.org/Archives/Public/www-style/2014Oct/0295.html |
| 09:02 | <annevk> | "CSSWG thinks Fullscreen should move to a Note referencing the WHATWG spec" |
| 09:04 | <annevk> | TabAtkins: is it still on the CSSWG's radar the changes Fullscreen does to CSS' rendering model need to move to CSS one day? |
| 09:25 | <annevk> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=850684 |
| 09:32 | <MikeSmith> | annevk: http://validator.w3.org/nu/?doc=https://html.spec.whatwg.org/multipage/ now gives an SSL-related error |
| 09:32 | <MikeSmith> | I'm not sure why, because http://validator.nu/?doc=https://html.spec.whatwg.org does not |
| 09:32 | <MikeSmith> | I suspect it might be a JVM difference but I really don't know |
| 09:34 | <MikeSmith> | I can work around it by using a runtime option with the validator instance to turn off checking of the TLS cert trust chain |
| 09:35 | <MikeSmith> | it could be that hsivonen is already using that option with the validator.nu but I think he's not. that's why I'm puzzled about why else there would be different behavior |
| 09:38 | <MikeSmith> | another weird difference is http://validator.w3.org/nu/?doc=https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions |
| 09:38 | <MikeSmith> | vs http://validator.nu/?doc=https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions |
| 09:40 | <MikeSmith> | it seems that wiki page is getting served to validator.w3.org/nu with an application/xml MIME type, while validator.nu is getting text/html as expected. I don't know why it would be getting served any differently. |
| 09:43 | <annevk> | MikeSmith: works fine in validator.nu |
| 09:43 | <annevk> | MikeSmith: "Element style is missing required attribute type." is that still required in SVG? |
| 09:44 | <annevk> | "Attribute role not allowed on element svg at this point.", "Attribute aria-label not allowed on element svg at this point." |
| 09:44 | <MikeSmith> | yeah, the fact that it works fine in validator.nu is what I'm puzzled about |
| 09:44 | <annevk> | These seem like bugs in either the validator or SVG |
| 09:44 | <annevk> | "Stream length exceeds limit." is a validator.nu bug |
| 09:46 | <MikeSmith> | about SVG and role, there is no spec that defines document-conformance rules for the role attribute. So to have the validator not flag it as an error, I basically just to have to make up some rule(s) |
| 09:46 | <annevk> | MikeSmith: well, guess time has come for the validator to upgrade its TLS internals |
| 09:46 | <MikeSmith> | yeah |
| 09:47 | <MikeSmith> | the thing is, I'm pretty sure the next time Henri redeploys validator.nu it will behave the same way the w3c instance is behaving now |
| 09:48 | <MikeSmith> | or when the java environment on the validator.nu host is upgraded |
| 09:49 | <MikeSmith> | validator.nu is running an older version of the sources so it's possible that some change I made to the sources since the last time Henri synced up is causing the difference but if so I have no idea what. I haven't touched an code recently that would affect this, as far as I can tell |
| 09:52 | <MikeSmith> | annevk: about "Element style is missing required attribute type." and SVG I don't know what's currently required for that in SVG. But the validator only implements SVG 1.1 support and for that it relies on an RelaxNG schema that's not completely up to date with the changes that SVG WG made to SVG 1.1 a couple years ago |
| 09:53 | <MikeSmith> | the did an "SVG 1.1 2nd Edition" thing similar to what the XML WG did with XML 1.0 |
| 10:00 | <annevk> | Ah I remember |
| 10:01 | <annevk> | SVG still seems somewhat lacking in resources to get their specification stuff in order |
| 10:06 | <annevk> | So in http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 they never define what they mean by domain, subdomain, and host name |
| 10:06 | <annevk> | And for IP addresses they reference 3986 but I'm pretty sure Google would recognize http://0x00034234/ as IP address |
| 10:11 | <MikeSmith> | annevk: Are you studying this for the purpose of adding a definition of "domain" to the URL spec |
| 10:12 | MikeSmith | tries to remember if the bug he raised about that is still open |
| 10:15 | <MikeSmith> | annevk: about SVG WG, I asked them if somebody from the group who cares could please update their RelaxNG SVG 1.1 schema to match the 2nd-edition updates they made and the response was pretty much just a "sorry no" shrug. |
| 10:17 | <annevk> | MikeSmith: the syntax bug is still open, I'm hoping the Unicode consortium will address it |
| 10:17 | <MikeSmith> | so if nobody from the group cares to take time to do that, it's annoying that they're expecting me to care about more than they do -- that is, that I need to be the one to care about it enough to actually update the validator support for it |
| 10:17 | <MikeSmith> | annevk: ok |
| 10:17 | <MikeSmith> | that would be nice |
| 10:18 | <annevk> | MikeSmith: I was mostly wondering, the document also uses the term superdomain |
| 10:19 | <annevk> | MikeSmith: and I understand what they mean I think, but I like things to be defined from first principles (e.g. is dom.spec.html5.org a subdomain of html5.org? for the purposes of certificates that is not the case) |
| 10:19 | <annevk> | They also reference HTML4 which is just insane |
| 10:28 | <MikeSmith> | annevk: yeah, surprised by that HTML4 reference. I wouldn't think Ryan or Chris Evans would use that as a reference. So I wonder if some IETF reviewer asked for it to be changed. |
| 10:29 | <annevk> | MikeSmith: yeah, it's the kind of thing where everyone that knows, knows it's wrong, but new people will be utterly confused |
| 10:29 | <annevk> | MikeSmith: and normative reference pedants will be pleased they saved the day |
| 10:29 | <MikeSmith> | :( |
| 10:30 | <MikeSmith> | I hope that's now what happened though, and they can just change it |
| 10:30 | <MikeSmith> | *not what happened |
| 10:31 | <MikeSmith> | anyway as far as dom.spec.html5.org being a "subdomain" of html5.org I'd think most people would intuitively say yeah, it would be |
| 10:31 | <annevk> | MikeSmith: come on, your work for the organization that references an obsolete MIME Sniffing draft from the IETF that is three years expired now over something maintained from the WHATWG (updated last month) in its flagship specification |
| 10:31 | <MikeSmith> | I think otherwise people would wonder well what is a subdomain then if not that |
| 10:31 | <annevk> | s/your/you/ |
| 10:32 | <MikeSmith> | yeah point taken |
| 10:47 | <annevk> | Should probably define subdomain, superdomain, effective tld, etc. in URL at some point |
| 11:10 | <MikeSmith> | annevk: so, what would be a simple explanation of what a subdomain actually is? |
| 11:13 | <annevk> | I guess it's always relative to a domain name |
| 11:17 | <annevk> | A domain /s/ is a subdomain of a domain /d/ if /s/ has more labels than /d/ and all /d/'s labels are at the end of /s/ labels, preserving order |
| 11:17 | <annevk> | Need better wording |
| 11:21 | <MikeSmith> | annevk: ah that whole labels thing |
| 11:21 | <MikeSmith> | isn't there some way to define it just in reference to DNS? |
| 11:24 | <annevk> | MikeSmith: that'd require DNS lookups, no? |
| 11:24 | <annevk> | MikeSmith: seems undesirable |
| 11:36 | <MikeSmith> | annevk: no I don't mean defining it in terms of DNS lookups but instead just in terms of whatever language from the DNS specs |
| 11:36 | <MikeSmith> | maybe that makes no sense |
| 11:36 | <MikeSmith> | was just thinking out loud |
| 11:36 | <annevk> | MikeSmith: ah yeah, I don't think DNS works in that way |
| 11:38 | <annevk> | MikeSmith: actually, I'm not sure, but last time I looked at those documents I did not become any wiser |
| 11:38 | <annevk> | MikeSmith: they certainly don't deal with things like effective TLD though and I'd like that to be defined in some standard as well |
| 11:38 | <MikeSmith> | ok |
| 11:46 | <MikeSmith> | annevk: these days I really miss working at Opera |
| 11:47 | <MikeSmith> | at least the Opera of the time back when I was there |
| 11:47 | <Ms2ger> | Do we not have any script execution tests in wpt? |
| 11:48 | <MikeSmith> | annevk: people with crazy ideas and a place that could actually help make them happen without layers of bureaucracy interfering |
| 11:50 | <MikeSmith> | Ms2ger: for which part of the spec? |
| 12:20 | <annevk> | MikeSmith: I just thought we could actually define subdomain as some kind of substring match |
| 12:21 | <annevk> | MikeSmith: isSubdomain(domainA.endsWith("." + domainB)) |
| 12:21 | <annevk> | MikeSmith: same for superdomain |
| 12:22 | <annevk> | MikeSmith: that doesn't help with defining *.html5.org certificate stuff of course |
| 12:22 | <annevk> | MikeSmith: yeah, old Opera was nice |
| 12:26 | <MikeSmith> | annevk: yeah outside of the issue of the certificate stuff, defining it just in terms of substring matches seems right. But it would be nice to be able to do that without talking about "labels" |
| 12:26 | <MikeSmith> | maybe it's not possible without talking about labels though |
| 12:27 | <annevk> | Your dislike for labels is noted :-) |
| 12:27 | <MikeSmith> | heh |
| 12:27 | <annevk> | Subdomain seems possible to define without |
| 12:27 | <annevk> | Superdomain too |
| 12:28 | <annevk> | However, *.html5.org... |
| 12:31 | <MikeSmith> | "label" is just not a term that I think most people are familiar with in relation to domain names. But then specs aren't written for most people. It just seems like it should always be a goal to define things in familiar terms when possible -- with an emphasis on the "when possible" of course |
| 12:31 | <MikeSmith> | like using "URL" instead of "URI" |
| 12:31 | <annevk> | I've heard people say "level" |
| 12:32 | <annevk> | Actually matches with top-level domain |
| 12:32 | <MikeSmith> | ah yeah that's closer at least |
| 12:32 | <MikeSmith> | yeah |
| 12:32 | <MikeSmith> | that fits better with the conceptual model |
| 12:35 | <MikeSmith> | but then I guess you still need something that identifies the particular level and then you're back to "label" really |
| 12:35 | <MikeSmith> | so I guess I should give up |
| 12:36 | <MikeSmith> | but... maybe "component"? |
| 12:36 | <MikeSmith> | domain-name components |
| 12:41 | <annevk> | MikeSmith: we could say that a domain is a stack of domain levels |
| 12:41 | <MikeSmith> | stack is good |
| 12:56 | <MikeSmith> | annevk: anyway about Opera it's hard to imagine anybody else coming up with something like browser.js and managing to actually ship it |
| 13:12 | <SteveF_> | MikeSmith:hey so you are saying that the SVG working group will need to do same for 1.1 as they have for 2 |
| 13:13 | <MikeSmith> | SteveF_: yup |
| 13:14 | <SteveF_> | MikeSmith: why? where elements defined in 1.1 are same as those in 2 why can't you use the role mappings? |
| 13:14 | <MikeSmith> | SteveF_: I can't just unilaterally invent ARIA-in-SVG1.1 rules for the validator |
| 13:14 | <SteveF_> | MikeSmith: ok so what will you accept? an editors draft or some such? |
| 13:16 | <MikeSmith> | SteveF_: an ARIA-in-SVG1.1 spec of any kind, anywhere |
| 13:16 | <SteveF_> | MikeSmith: OK |
| 13:16 | <SteveF_> | will talk to rich |
| 13:16 | <MikeSmith> | cool |
| 13:24 | <MikeSmith> | SteveF_: I guess if things were saner w.r.t spec versioning at the W3C or I were personally to take an enlightened view, I could consider the SVG2 spec a living spec that supersedes the SVG1.1 spec |
| 13:26 | <SteveF_> | MikeSmith: well in terms of usefulness for checker users an enlightened view would help |
| 13:28 | <SteveF_> | MikeSmith: and I am sure that a 1.1 mapping spec can be whipped up using the info from the svg2 spec, but seems like enrgy user, but if that is what it takes to get sane error spits then will see what I can do |
| 13:31 | <MikeSmith> | SteveF_: you're a better man than me :) |
| 13:33 | <SteveF_> | MikeSmith: we advocate use of ARIA on SVG in HTML of whatever flavour to make up for current acc layer fuck ups in browsers, so having them not throw errors in conformance would be helpful |
| 13:33 | <SteveF_> | MikeSmith: for example http://www.paciellogroup.com/blog/2013/12/using-aria-enhance-svg-accessibility/ |
| 13:34 | MikeSmith | looks |
| 13:35 | <MikeSmith> | wow |
| 13:35 | <MikeSmith> | so the problem here is not just the document-conformance stuff |
| 13:36 | <MikeSmith> | SteveF_: there's also no spec that defines the mappings for the native SVG elements to the a11y APIs? |
| 13:37 | <SteveF_> | MikeSmith: there is start of one http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html |
| 13:38 | <MikeSmith> | if there's no spec for browser projects to implement from it seems not really suprising that the browser implementations aren't consistent |
| 13:38 | MikeSmith | looks |
| 13:38 | <MikeSmith> | ah good |
| 13:38 | <SteveF_> | also note that SVG2 tabindex has been implemented in webkit http://trac.webkit.org/changeset/168313 and believe that its on its way elesehwere |
| 13:39 | MikeSmith | looks |
| 13:41 | <SteveF_> | MikeSmith: FF svg tabindex https://bugzilla.mozilla.org/show_bug.cgi?id=778654 |
| 13:41 | <MikeSmith> | SteveF_: has that landed? |
| 13:42 | <SteveF_> | dunno |
| 13:42 | <SteveF_> | looks like it has in chrome https://codereview.chromium.org/166163005/ |
| 13:43 | <MikeSmith> | ah yeah |
| 13:43 | <MikeSmith> | good on ed |
| 13:45 | <SteveF_> | MikeSmith: so anyway we can chat at tpac about checker support, rich will be there too and he has been driving the svg2/acc stuff |
| 13:46 | <MikeSmith> | super |
| 13:46 | <MikeSmith> | yeah let's do that for sure |
| 15:36 | <TabAtkins> | annevk: Yeah, rendering model changes are still in out demesne, obviously. |
| 17:23 | <annevk> | TabAtkins: demsne? |
| 17:24 | <TabAtkins> | domain, but fancier |
| 17:25 | <annevk> | ah, and out is fancy for our |
| 17:25 | <annevk> | got it |
| 17:26 | <jgraham> | Is TabAtkins inventing a whole new language? |
| 17:27 | <TabAtkins> | that's, uh, english |
| 17:37 | <jgraham> | Well I guess it's only a dialect |
| 17:37 | <jgraham> | Tabese |
| 17:38 | <TabAtkins> | http://lmgtfy.com/?q=define+demesne |
| 17:41 | <jgraham> | You don't really seem to be talking about land owned by a manor though |
| 17:52 | <TabAtkins> | No, but it is used figuratively in that sense, in the same way "domain" is. |
| 19:05 | <foolip> | TabAtkins: in spec references, should you be "T. Atkins", "T. Atkins Jr." or something else? |
| 19:06 | <foolip> | I just noticed http://dev.w3.org/html5/webvtt/ does both |
| 19:06 | <foolip> | also, http://www.w3.org/TR/selectors4/ or http://dev.w3.org/csswg/selectors/ ? |
| 19:13 | <TabAtkins> | foolip: Tab Atkins Jr |
| 19:14 | <foolip> | TabAtkins: what about in specs where everyone else is on the form "H. Lie" etc? |
| 19:14 | <TabAtkins> | I'm inconsistent in whether I put a Jr on my name. |
| 19:14 | <TabAtkins> | That's just an artifact of the biblio generation script. |
| 19:15 | <foolip> | unfortunately not in the case of webvtt or e.g. html, it's abbreviated in the source |
| 19:16 | <foolip> | but I'll take that as "include Jr" |
| 19:16 | <foolip> | how about the selectors ref? |
| 19:46 | <foolip> | TabAtkins: ^ |
| 20:05 | <annevk> | foolip: euhm, no TR/! |
| 20:14 | <foolip> | annevk: right, but see https://github.com/w3c/webvtt/commit/c7c658fd914e4e196f462fd49fbd30603fe76503 |
| 20:14 | <annevk> | o_O |
| 20:15 | <foolip> | there's also http://dev.w3.org/csswg/selectors4/ |
| 20:16 | <foolip> | annevk: are you going to link IndexSizeError and friends in DOM to their new home in WebIDL? |
| 20:16 | <foolip> | I just noticed the IndexSizeError in WebVTT was broken |
| 20:16 | <annevk> | foolip: I xref throw from DOM |
| 20:16 | <annevk> | foolip: I don't xref the individual errors |
| 20:17 | <annevk> | foolip: I suspect I might start doing that again one day by having TabAtkins support it in Bikeshed |
| 20:17 | <foolip> | I see |
| 20:18 | TabAtkins | is at lunch right now |
| 20:18 | <annevk> | TabAtkins: we can wait an hour :p |
| 20:48 | <Domenic> | Why do you have to do new WheelEvent("wheel", ...)? |
| 20:49 | <Domenic> | that first parameter seems useless... |
| 20:52 | <foolip> | Domenic: some (most?) event interfaces have multiple events |
| 20:52 | <foolip> | I'm guessing it's new MouseEvent("mousedown", ...) etc |
| 20:53 | <Domenic> | Ah right, that makes sense |
| 20:54 | <Domenic> | You could imagine nicer designs but OK. |
| 21:02 | <caitp> | domenic, how would you rate the web-compat for Symbol.toStringTag (and related semantics based on it)? |
| 21:23 | <foolip> | TabAtkins: you should add Jr. to http://dev.w3.org/csswg/css-values/ ? |
| 21:41 | <annevk> | Domenic: the name/type of an event is very much distinct of its class |