| 03:16 | <Hixie> | (i am on a plane and shall now respond to the last few days of comments. apologies for not reading the current state of the channel as i do this) |
| 03:16 | <Hixie> | SamB: json doesn't prevent injection attacks any more than xml prevents injection attacks |
| 03:16 | <Hixie> | TabAtkins: my understanding is that there's no rule about not referring to whatwg specs; if you are hearing differently, ping tantek. |
| 03:17 | <Hixie> | TabAtkins: (the w3c references plenty of specs that don't have patent policies, e.g. anything from the IETF) |
| 03:17 | <SamB> | Hixie: it's one less place to screw that up ... |
| 03:18 | <Hixie> | MikeSmith: yeah, i'm aware of thatcher's opinions on consensus. One of the few things she was quite right about. ;-) |
| 03:26 | <Hixie> | cwilso: the whatwg has the same fence as the w3c (no fence). well, the w3c has a pretend fence, but it has the same effect. |
| 03:27 | <Hixie> | cwilso: (the most obvious proof of which is the way the w3c keeps arbitrarily forking our specs) |
| 03:30 | <Hixie> | SamB: not really. I'm saying people should write their parsers at the unicode level, you're saying they should write them at the JSON level. It's one fewer layer to go wrong. |
| 03:32 | <Hixie> | ok closing laptop now, going in for landing. |
| 05:27 | <zcorpan> | SimonSapin: because of <html>foo<html foo> you need to "buffer" the whole document |
| 10:20 | <hsivonen> | annevk: what is Windows code page 29001 x-europa? |
| 10:21 | <hsivonen> | today I learned: LDAP uses T.61 |
| 10:21 | <hsivonen> | at least in theory |
| 10:21 | <hsivonen> | also: Mozilla LDAP code doesn't used the Mozilla T.61 converter |
| 10:24 | <annevk> | hsivonen: I don't know |
| 10:25 | <annevk> | hsivonen: seems it's "Europa 3" but I've no idea what that is |
| 10:41 | <Ms2ger> | zcorpan_, hey, did you see https://bugzilla.mozilla.org/show_bug.cgi?id=998298 ? |
| 10:42 | <zcorpan_> | Ms2ger: yeah. what about it? |
| 10:43 | <Ms2ger> | I was hoping you'd suddenly feel like fixing the test :) |
| 10:46 | <zcorpan_> | oh. ok. not right now but i can put it on my list |
| 10:47 | <zcorpan_> | didn't gecko drop microdata? |
| 10:50 | <zcorpan_> | seems not |
| 10:53 | <zcorpan_> | Ms2ger: i'll probably not spend time on microdata tests until the api is implemented in blink again |
| 10:54 | <Ms2ger> | Alright, thanks |
| 11:07 | <annevk> | JakeA: the way the service worker specification is written at the moment reads like a tutorial |
| 11:08 | <annevk> | JakeA: e.g. "After successful installation and just prior to receiving functional events (e.g., fetch), the activate event is dispatched." |
| 11:20 | <JakeA> | annevk: I didn't write that line, fwiw I think it's wrong |
| 11:20 | <annevk> | JakeA: it seems also somewhat odd that there's an "Algorithms" section |
| 11:21 | <Ms2ger> | Is there also a "Data Structures" one? |
| 11:21 | <JakeA> | annevk: probably because those were developed separately. I guess they should be rolled into their relevant methods |
| 11:22 | <annevk> | JakeA: IDL of FetchEvent also seems somewhat botched; e.g. you can reply with an OpaqueResponse, so respondWith should take an AbstractResponse |
| 11:23 | <Ms2ger> | hsivonen, I assume not "T-61 Euthanasia Solution (Canada) for Animal Use" |
| 11:24 | <JakeA> | annevk: will fix that now |
| 11:29 | <annevk> | JakeA: filed https://github.com/slightlyoff/ServiceWorker/issues/242 |
| 11:39 | <zcorpan_> | annevk: url spec has no limit on the port number? |
| 11:40 | <annevk> | zcorpan_: no |
| 11:40 | <zcorpan_> | annevk: why not? |
| 11:40 | <annevk> | zcorpan_: seemed arbitrary |
| 11:43 | <annevk> | Hmm, the current service worker specification seems kind of bad :-( |
| 11:59 | <zcorpan_> | annevk: where does the url spec make the windows drive letter quirk invalid? |
| 12:00 | <annevk> | JakeA: what does waitUntil() do? |
| 12:00 | <annevk> | JakeA: does it set any event flags? |
| 12:01 | <KevinMarks_> | is http://www.w3.org/TR/media-frags/ compatible with HTML5? it allows spaces in id's |
| 12:02 | <annevk> | KevinMarks_: does it not escape them? |
| 12:02 | <KevinMarks_> | it does, but how can they match ids? |
| 12:03 | <annevk> | KevinMarks_: could you give a more specific pointer maybe? |
| 12:03 | <JakeA> | annevk: It's slightly different per event. In install, the supplied promises define the length & success of the installation phase of the lifecycle |
| 12:03 | <JakeA> | annevk: In activate, the supplied promises define only the length of the activation phase |
| 12:04 | <KevinMarks_> | http://www.w3.org/TR/media-frags/#general-structure has http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202 |
| 12:04 | <annevk> | JakeA: what about pagereload? |
| 12:04 | <KevinMarks_> | id this dimension denotes a named temporal fragment within the original media, such as "chapter 2", and can be seen as a convenient way of specifying a temporal fragment. |
| 12:04 | <annevk> | KevinMarks_: that's not an HTML ID |
| 12:04 | <annevk> | KevinMarks_: or DOM ID |
| 12:05 | <KevinMarks_> | OK, that's what I thought. |
| 12:05 | <JakeA> | annevk: There it delays the reload for the length of the promises |
| 12:05 | <KevinMarks_> | so it's not a constraint on fragmentions within HTML |
| 12:07 | <annevk> | JakeA: what if the promise rejects? |
| 12:07 | <annevk> | JakeA: anyway, it never sets the canceled flag I guess? |
| 12:08 | <annevk> | JakeA: seems kind of weird this mix between promises and events |
| 12:09 | <JakeA> | annevk: A rejection aborts the reloadAll process |
| 12:13 | <annevk> | Hmm okay, so it somewhat augments the event dispatch process, I guess that's sort of within the line of what's okay, but somewhat weird |
| 12:34 | <annevk> | JakeA: actually, looking at the algorithms, a lot of them don't seem to talk about queueing events and probably should |
| 12:34 | <annevk> | JakeA: you can't just dispatch events at a set of documents |
| 12:35 | <annevk> | JakeA: and usually we don't talk about things like "serviceWorkerRegistration.currentWorker" as .currentWorker can be changed by script |
| 12:37 | <JakeA> | annevk: "queuing events" - is that to make it clear it's an async operation? |
| 12:37 | <annevk> | JakeA: yes and to make it clear when it happens relative to other asynchronous tasks |
| 12:37 | <JakeA> | annevk: serviceWorkerRegistration is a private object, it's only used within the spec |
| 12:37 | <annevk> | JakeA: see HTML's event loop definition |
| 12:54 | <JakeA> | annevk: Is there precedent for firing events across a set of documents then doing something with the result (eg, if some or all defaultPrevented)? |
| 12:55 | <annevk> | JakeA: not really, especially not with waitUntil weirdness |
| 12:56 | <annevk> | JakeA: you'd have to queue tasks that dispatch the events, check the return value, and report via some callback |
| 12:56 | <annevk> | JakeA: and then I guess you'd say "wait until all have reported back" in some kind of language that makes Domenic_ happy |
| 12:56 | <JakeA> | annevk: figured the reloadAll stuff would be difficult. Cheers. |
| 12:57 | <annevk> | JakeA: this spec needs a lot more infrastructure around it |
| 12:57 | <annevk> | JakeA: this is also true for a bunch of the other events, though they're less involved I suppose |
| 12:58 | <annevk> | JakeA: but all the across boundary stuff is hard, and service workers is full of it |
| 12:58 | <JakeA> | worth it though, at least I hope |
| 12:59 | <annevk> | oh yeah, it's just a bit annoying that the current spec doesn't really seem to grasp what it's doing |
| 13:01 | <JakeA> | yeah, next iteration needs to remove the vagueness |
| 13:23 | <JakeA> | Btw, the w3 guys are wanting to drop the outline algorithm from html5 but keep sectioning elements https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 |
| 13:24 | <JakeA> | meaning adding it back in later breaks backwards compatibility |
| 13:28 | <annevk> | JakeA: wtf |
| 13:28 | <JakeA> | I know right |
| 13:28 | <annevk> | W3C HTML is crazy town |
| 13:29 | <SteveF> | JakeA: incorrect - not w3 guys dropping outline algorithm, as you know - implementers who have commented are borking at implementing acc layer implementation |
| 13:29 | <SteveF> | JakeA: spreading misinfo not helpful |
| 13:30 | <JakeA> | The acc layer is where the outline is important |
| 13:31 | <SteveF> | JakeA: convince the implementers |
| 13:31 | <SteveF> | you have reps from firefox/chrome/webkit on that bug |
| 13:32 | <JakeA> | and I'm responding to that bug |
| 13:32 | <JakeA> | and also filing issues with Chrome & looping in the other vendors |
| 13:33 | <SteveF> | so why you blowing smoke then? |
| 13:34 | <SteveF> | singing to choir about the "W3C HTML is crazy town" |
| 13:34 | <JakeA> | Because the w3 are creating a situation where adopting the outline at the acc layer becomes a backwards incompatible change |
| 13:34 | <SteveF> | JakeA: how so? |
| 13:35 | <JakeA> | Because you're keeping sectioning elements, but dropping the outline from acc. They were introduced at the same time to avoid that. |
| 13:35 | <JakeA> | Because you're saying that section > h1 should be heading level 1. A later introduction of outlining to the acc layer means it becomes heading level 2 |
| 13:35 | <SteveF> | the outline is not implemented in acc layer all that is being discussed is reflecting what is implemented |
| 13:37 | <SteveF> | that is what is, not asking to implement anything |
| 13:39 | <annevk> | If you don't want outline, drop <section> & friends too |
| 13:39 | <annevk> | Pretty much the sole reason they are useful is influencing heading levels |
| 13:39 | <JakeA> | Right, but if it's introduced to "5.1", that makes 5.1 backwards incompatible with 5.0. To avoid that you need to drop all sectioning elements |
| 13:42 | <SteveF> | annevk: its not me that does or doesn't want it its the implementers |
| 13:43 | <annevk> | Outline is not just for accessibility, it's also for new selectors |
| 13:43 | <annevk> | And being able to organize content better |
| 13:44 | <annevk> | What Marco Zehe says in that bug is not true for all of Mozilla |
| 13:45 | <SteveF> | annevk: and as I have said the outline is not being dropped, we are discussing the modding of the requirement that has not been implemnted |
| 13:45 | <SteveF> | annevk: sure nobody speaks for all mozilla do they? but we are talking about acc related stuff so you duke it out with the acc guys if you have an issue with what they are saying |
| 13:45 | <JakeA> | annevk: I think what SteveF is suggesting is that the outline stuff would stay in the spec, but that a11y should only use the heading number, which makes it inconsistent |
| 13:46 | <wilhelm> | Have browser vendors given any indication on when they'd implement this, if ever? |
| 13:46 | <annevk> | wilhelm: I would guess it's generally low priority |
| 13:47 | <JakeA> | No one's filed a ticket for it, until now |
| 13:47 | <JakeA> | https://code.google.com/p/chromium/issues/detail?id=365070#c2 |
| 13:48 | <SteveF> | JakeA: I am saying that what every browser does now is implement acc as I have indicated in that bug = current interop implementations |
| 13:48 | <annevk> | SteveF: yes, you have demonstrated nobody implements <section>; job well done |
| 13:49 | <annevk> | SteveF: your solution however makes <section> unusable forever |
| 13:49 | <annevk> | which is why we dub W3C HTML "crazy town" |
| 13:49 | <annevk> | or I do, anyway |
| 13:49 | <SteveF> | annevk: my solution? |
| 13:50 | <JakeA> | Dropping the acc requirement, meaning that outline isn't applied, meaning that section isn't applied |
| 13:51 | <wilhelm> | I hit the "all headings are the same level, WTF" issue when testing with screenreader users recently. Discouraging using <section>+<h1> is sensible until the outline algoirthm is actually implemented, but dropping just half of it in the spec sounds like it will just cause more confusion. |
| 13:52 | <JakeA> | wilhelm: A small polyfil that sets role="heading" and aria-level will fix it in browsers & ATs that support those things |
| 13:53 | <JakeA> | wilhelm: it'll cause confusion, but worse it causes backwards incompatibility. Conformant "HTML 5.0" sites will break in browsers+AT that support "HTML 5.1" and vice versa |
| 13:54 | <wilhelm> | JakeA: I hadn't thought of polyfilling that particular issue. That's a good idea. |
| 13:54 | <SteveF> | JakeA: using H1-H6 old style in conjunction with sections is fully backward compatible |
| 13:54 | <webben> | JakeA: The change wouldn't change the HTML5 CR along with HTML5.1? |
| 13:54 | <SteveF> | JakeA: telling devs to use h1 is not |
| 13:55 | <webben> | *The proposal |
| 13:55 | <annevk> | JakeA: should .client and .purpose be on Request? |
| 13:56 | <JakeA> | webben: still results in broken sites |
| 13:56 | <webben> | JakeA: Is <section><h1> to mean something other than heading level 1 in common use today? |
| 13:56 | <SteveF> | JakeA: how so? |
| 13:58 | <JakeA> | annevk: I think the intention was to separate the request from the situation that generated it |
| 13:58 | <JakeA> | annevk: As in, a fetch with purpose "image" may have added extra things to the accept header of the request |
| 13:58 | <SteveF> | webben: the proposal is to mod HTML5 to reflect current implementations leaving 5.1 to reflect desired implementation |
| 13:58 | <annevk> | JakeA: a fetch from origin will have done so too |
| 13:58 | <wilhelm> | SteveF: This document would be different in 5.0 and 5.1: <section><h1/> <section><h1/></section></section> |
| 13:59 | <JakeA> | webben: yes |
| 13:59 | <annevk> | JakeA: if you want to really separate them, we'd have to trim Request more |
| 13:59 | <webben> | JakeA: Are there any stats around that? |
| 13:59 | <annevk> | JakeA: which may be worth doing |
| 13:59 | <annevk> | JakeA: but will be complex |
| 13:59 | <JakeA> | webben: Around use & misuse? |
| 14:00 | <JakeA> | annevk: I think it comes down to what should go into a cache and what shouldn't |
| 14:00 | <webben> | JakeA: Around use of <section><h1> to mean something other than heading level one in the wild. |
| 14:01 | <JakeA> | webben: I don't. I'm sure there are misuses, just like any element. |
| 14:01 | <annevk> | JakeA: right, what hits the network and what doesn't |
| 14:01 | <SteveF> | willhelm: then the answer is to define requirement as "no role" in 5.0 which means implementers can implement as they want |
| 14:01 | <webben> | JakeA: I'm not talking about misuses? |
| 14:01 | <annevk> | JakeA: might be worth doing long term |
| 14:02 | <SteveF> | willhelm: but doesn't cause the break - thanks! |
| 14:02 | <JakeA> | annevk: Doing what? |
| 14:02 | <annevk> | JakeA: I think in the Fetch Standard I'll keep them unified in the "request concept" for now |
| 14:02 | <webben> | JakeA: Per CR and Living Standard, <section><h1> can mean something other than heading level one. I'm wondering how widespread that actually is in the corpus. |
| 14:03 | <annevk> | JakeA: trimming request further and having a separate bag of bits that instructs the fetch algorithm to do various things |
| 14:03 | <JakeA> | webben: Straw poll in the office & most of us are using section to affect outline on our projects, but I realise that's not good evidence |
| 14:04 | <webben> | JakeA: e.g. if 0.0001% of pages that use <section><h1> use it to mean something other than heading level one, then always interpreting h1 as heading level one may result in better understanding of the corpus generally. |
| 14:04 | <wilhelm> | webben: My gut feeling from the projects I've worked on says it's widespread, but real data would be nice. |
| 14:04 | <JakeA> | annevk: Ahh yes, agreed. The request does need some private link to the requesting element for prioritisation etc. That link should be removed when it goes into caches. |
| 14:04 | <annevk> | JakeA: you need a link to the source for CSP, .client, referrer policy |
| 14:04 | <JakeA> | wilhelm: What would you look for? Number of sites that use <section> or number of sites that use <section> correctly? |
| 14:05 | <webben> | JakeA: I remember in the earlier days of HTML5's evolution, there were quite a lot of attempts to look at usage in the wild and redefine the semantics accordingly on the basis that it led to better understanding of the corpus as a whole. |
| 14:06 | <webben> | JakeA: You'd have to look for sites that use section to nest heading levels. It might be possible to approach that statistically (e.g. look for unusual nestings) but to be sure you'd probably have to do a qualitative inspection. |
| 14:06 | <JakeA> | webben: agreed |
| 14:06 | <webben> | (We had to do similar inspections for e.g. the summary attribute.) |
| 14:07 | <wilhelm> | JakeA: Finding sites containing <section> and more than one <h1> would give an indication. |
| 14:07 | <SteveF> | willhelm: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003#c25 |
| 14:08 | <webben> | wilhelm: Mmm. Multiple h1s is not that uncommon even without <section> |
| 14:09 | <webben> | wilhelm: There was a long-running markup debate about whether pages should use h1 for a title for the page or multiple h1s for different sections on the same page. |
| 14:10 | <annevk> | JakeA: btw, what about renaming .purpose to .context? |
| 14:11 | <wilhelm> | SteveF: I have not used that particular ARIA role before. Would that mean that all heading magic would disappear from the <section><h1> element? |
| 14:12 | <JakeA> | annevk: Not sure it's better, but not against it. Could it get confused with browsing context? |
| 14:14 | <annevk> | JakeA: it's not really a purpose is my main problem here |
| 14:15 | <JakeA> | "origin"! No, wait… |
| 14:15 | <JakeA> | annevk: Yeah, fair enough, context is better |
| 14:15 | <SteveF> | willhelm: magic where? |
| 14:15 | <annevk> | we decided to call browsing context a client |
| 14:15 | <annevk> | ok, will file |
| 14:18 | <wilhelm> | SteveF: I don't fully understand the implications of what you suggest in comment 25. (c: |
| 14:20 | <SteveF> | willhelm: currently there is an implementation requirement on browsers to map hx to outline depth - this is couched in terms of ARIA roles/properties which have mappings to platform acc APIs |
| 14:21 | <annevk> | JakeA: looking at http://fetch.spec.whatwg.org/#requests it seems method/url/headers/body are essential, everything else is parameters |
| 14:21 | <annevk> | JakeA: I can look into rephrasing things in that way, although it might make Fetch even harder to use from other specifications... |
| 14:21 | <annevk> | ugh |
| 14:21 | <SteveF> | willhelm: none of the browsers implement this they all implement soemthing else, as you pointed out, requiring they implement something esle in 5.0 and changing in 5.1 causes issue |
| 14:23 | <wilhelm> | So far I'm following. (c: |
| 14:24 | <SteveF> | willhelm: removing strict requirement from 5.0 , as its is not going to happen in 5.0 rec timeframe, but having it in 5.1 resolves issue |
| 14:25 | <wilhelm> | SteveF: So what exactly should browsers do right now to be compliant? "Whatever they want"? |
| 14:26 | <SteveF> | willhelm: the interop implementation of heading semantics is currently h1= heading level 1, h2 = heading level 2 etc |
| 14:28 | <SteveF> | willhelm: which will not chnage until the browsers decide to implement the new requriements |
| 14:28 | <JakeA> | annevk: hmm, maybe there's a better way. What do you need on the request obj to keep things easy? |
| 14:31 | <wilhelm> | SteveF: But then we're back to <section><h1> yielding two different outlines depending on whether a UA follows 5.0 or 5.1. Or do I misunderstand? |
| 14:31 | <JakeA> | wilhelm: nope, that's exactly the problem |
| 14:31 | <SteveF> | willhelm: the problem exists whatever the spec says the problem is in the implementations |
| 14:32 | <annevk> | JakeA: I dunno, I want to move this purpose/context thing into http://fetch.spec.whatwg.org/ somehow |
| 14:32 | <annevk> | JakeA: I also need the "client" concept there |
| 14:32 | <annevk> | JakeA: just wondering how we want to layer the whole stack |
| 14:33 | <JakeA> | annevk: Maybe we can put them there & drop them when they go into the cache |
| 14:33 | <annevk> | JakeA: I suppose we could also expose the request concept differently in the API |
| 14:34 | <annevk> | JakeA: there's a bit of a question too as to how this should all work with fetch() |
| 14:34 | <JakeA> | SteveF: The problem is when a spec breaks a compliant implementation, which is what you're talking about. Right now, non-compliant implementations are broken, |
| 14:34 | <webben> | SteveF: There doesn't _have_ to be an inconsistency in the versions of the spec. For instance, 5.0 could require <section> to be used so that <hX> elements are in order if <section> were not present. |
| 14:35 | <SteveF> | JakeA: what I have proposed after discussion does not break |
| 14:35 | <wilhelm> | SteveF: You'll have two versions of the spec that disagree with each other. You can't be compliant both with 5.0 and 5.1. |
| 14:35 | <webben> | SteveF: Or (I suppose) require aria-heading-level to be added where hX elements are nested "incorrectly". |
| 14:36 | <SteveF> | willhelm: yes you can |
| 14:36 | <SteveF> | i agree before you couldn't and thanks for pitning that out |
| 14:36 | <SteveF> | pointing |
| 14:37 | <webben> | wilhelm: I think you mena it is possible (for a document) to comply with 5.0 and not with 5.1. (One can always use <section><h1> such that it does not introduce conflicts of interpretation, i.e. redundantly.) |
| 14:37 | <webben> | *you mean |
| 14:39 | <annevk> | Hmm, Chrome wants to ship HTML imports |
| 14:39 | <Ms2ger> | Let's go to LC |
| 14:39 | <JakeA> | Wonder what happened to the render blocking stuff. slightlyoff? |
| 14:39 | <annevk> | Without any of the features ES modules have, such as scoping of names and such |
| 14:40 | <annevk> | JakeA: the latest I heard was that you specify async |
| 14:40 | <JakeA> | sadface |
| 14:40 | <JakeA> | We shouldn't be introducing new render-blocking features |
| 14:41 | <annevk> | Blog about it |
| 14:42 | <JakeA> | Already made a ton of noise about it internally. Maybe slightlyoff has more info. |
| 15:26 | <dglazkov> | good morning, Whatwg! |
| 15:26 | <annevk> | morning dglazkov |
| 15:26 | <cwilso> | hixie: the incorporation of whatwg output into w3c work does put a ladder across their fence, yes. We could have a more nuanced discussion of that dynamic; but the point of the W3C PP is getting major patent holders to mutually agree to x-license. |
| 15:27 | <cwilso> | hixie: s/their/W3C's |
| 15:27 | <cwilso> | good morning dglazkov! |
| 15:28 | <cwilso> | hixie: last I checked, whatwg is still wild west wrt ip. |
| 15:28 | <Hixie> | cwilso: well, the whatwg is a cg, it's using the cg model of regular FSAs. We just haven't actually done any, much like the w3c hasn't done any RECs. :-) |
| 15:29 | <Hixie> | cwilso: but i think you vastly overestimate the benefits of the patent policy. |
| 15:30 | <cwilso> | hixie: well, I'd say the whatwg uses a cg as one input, not "it does its work under the umbrella of a cg". But perhaps I'm mistaken. |
| 15:30 | <annevk> | cwilso: a CG's venue can be anywhere |
| 15:30 | <cwilso> | hixie: if you think I think a patent policy is some giant protective umbrella, then I can understand why you'd think I vastly overestimate its benefits. |
| 15:30 | <annevk> | cwilso: ours is whatwg⊙wo and this IRC channel, roughly |
| 15:31 | <cwilso> | annevk: indeed. Has everyone in whatwg@ and this irc channel signed up to the CG? |
| 15:33 | <Hixie> | the whatwg is a w3c cg, it does all the work under the cg umbrella |
| 15:33 | <cwilso> | hixie: but I'm not an idiot. Well, not about ip. there is nothing that can protect against someone else owning IP and pressing its advantage (e.g. EOLAS); the only useful goal is to get the major ip holders to participate in a venue where they've been kept "honest". |
| 15:33 | <Hixie> | right now all the "major ip holders" participate both in the cg and the wg |
| 15:33 | <Hixie> | so... |
| 15:33 | <cwilso> | hixie: and that's why it's not a complete disaster. |
| 15:34 | <Hixie> | well, it's why it _is_ a disaster, but for other reasons |
| 15:34 | <cwilso> | ha! |
| 15:34 | cwilso | afk |
| 15:35 | <Hixie> | anyway. i don't really understand what threat model you're concerned about which the REC process deals with but the FSA process doesn't. |
| 15:42 | <annevk> | JakeA: for the algorithms you need to clarify what kind of exceptions you are rejecting with |
| 15:42 | <annevk> | JakeA: and you want to reference terms such as "document url" somehow |
| 15:42 | <annevk> | JakeA: and link to the URL parser when you parse URLs (rather than just say "resolved" which doesn't mean much these days) |
| 15:42 | <annevk> | JakeA: if you want I can go through the algorithms at one point and file issues |
| 15:43 | <annevk> | JakeA: or we can keep doing this |
| 15:46 | <TabAtkins> | annevk: Mind chatting about element-tree vs DOM in real-time? I'm on the fence. |
| 15:46 | <dglazkov> | what's element-tree? that sounds awesome |
| 15:46 | <annevk> | TabAtkins: can do |
| 15:46 | <TabAtkins> | dglazkov: The abstraction I currently have in Selectors of the document tree. ^_^ |
| 15:47 | <TabAtkins> | annevk: Cool. So your arguments are definitely pulling me towards just using DOM. But I'm not 100% convinced yet. Mainly it's the idea that there is still info not present in the DOM that Selectors uses, like pseudo-elements. You make some argument about PEs that I don't quite understand in that last email. |
| 15:48 | <TabAtkins> | I think it's reasonable (and probably easier) to consider that PEs are always in the tree. |
| 15:48 | <JakeA> | annevk: issues would be great. I thought I'd added exceptions to the rejects, guess I missed some |
| 15:48 | <annevk> | JakeA: you did, but what is "NetworkError"? |
| 15:49 | <annevk> | TabAtkins: so your argument is that ::before and ::after are in the DOM? |
| 15:49 | <JakeA> | annevk: I thought I found that in the dom spec |
| 15:49 | <TabAtkins> | annevk: Yeah. |
| 15:49 | <annevk> | TabAtkins: I always thought of them as to be in the box tree |
| 15:49 | <TabAtkins> | annevk: Nah, properties get first applied to elements, so they're in the element tree. |
| 15:49 | <TabAtkins> | Boxes get generated from elements, based on 'display' and other things. |
| 15:50 | <TabAtkins> | That is, a ::before (pseudo-) element is set to display:block and content: "foo", it generates a block box that forgets about where it came from. |
| 15:50 | <annevk> | JakeA: if you reuse those, you also need to reuse the "throw" glue as otherwise it isn't clear what object is being used |
| 15:51 | <annevk> | TabAtkins: currently there's nothing that requires pseudo-elements to be in the node tree |
| 15:51 | <annevk> | TabAtkins: an implementation could only have them in the box tree, and I think Firefox might do that |
| 15:51 | <TabAtkins> | Right, nothing *requires* them, but it makes the overall model simpler. |
| 15:51 | <annevk> | TabAtkins: not if that model is not defined ^_^ |
| 15:52 | <TabAtkins> | I doubt FF has pseudo-elements actually in the box tree. It might only *generate* boxes for PEs (and not actually keep anything representing them in the tree that selectors are run over), which is fine. |
| 15:52 | <annevk> | (Text selection and such might require them to be I suppose. Once we really nail that it'll become observable one way or another.) |
| 15:52 | <TabAtkins> | Defining that model is what I'm trying to do (sorta gradually, but mostly I'm holding off until I resolve your issues). |
| 15:53 | <TabAtkins> | If you think it's okay to say that Selectors operates on the DOM, augmented with X and Y concepts, I think I can work with that. |
| 15:54 | <annevk> | Yeah, I think that would make sense. You'd define that elements have an additional ::after and ::before slot, and that these get returned when you use a pseudo-element |
| 15:54 | <annevk> | And then the algorithm that takes a style sheet and a node tree, also looks at element's their ::after and ::before slot |
| 15:54 | <TabAtkins> | (+ multiple other pseudo-element slots) |
| 15:55 | <TabAtkins> | So, one complication. Some pseudo-elements can contain real elements. |
| 15:55 | <annevk> | Yeah, it could be generic I suppose |
| 15:55 | <TabAtkins> | Such as ::shadow containing the contents of the shadow tree. |
| 15:55 | <TabAtkins> | Does this disturb anything? |
| 15:55 | <annevk> | I would expect that selector to be split and separately matched. Is that correct? |
| 15:56 | <TabAtkins> | Depends on how you work it internally. That's possible, sure. |
| 15:56 | <TabAtkins> | foo::shadow bar just means "find a foo element in your current context, find its shadow root, then find a bar descendant". |
| 15:57 | <TabAtkins> | You can interpret it similar to combinators, rather than as splitting the selector up, if you want. |
| 15:57 | <annevk> | Should that not be a combinator then? Or is is ::shadow also a box of sorts? |
| 15:58 | <annevk> | But I think that works, you just have to define the distinct trees that need to be matched upon |
| 15:58 | <annevk> | But if that's not a combinator that also makes it complicated for what we want .query() to do when passed ::shadow vs what we want when you pass ::before |
| 15:59 | <TabAtkins> | ::shadow matches the shadow root. Currently that's indistinguishable from a combinator, but it's possible for a specialized API to actually *return* the ShadowRoot object from a selector like "foo::shadow", for example. |
| 15:59 | <TabAtkins> | Nah, the "match a selector" algo already handles pseudos. You just have to specify what pseudos, if any, you want to be allowed to be returned by it. |
| 15:59 | <annevk> | Whoa, if we want that then that should be raised quickly, currently .query only returns elements |
| 16:00 | <TabAtkins> | I dunno if it's useful! But it is possible. |
| 16:00 | <TabAtkins> | (Similarly, ::content might be able to return something, though I don't think we have a specialized object for it yet.) |
| 16:01 | <TabAtkins> | annevk: How quickly do you think we need to define a PseudoElement interface if we want .query() to be able to return it? |
| 16:01 | <Ms2ger> | Let's just ship it |
| 16:02 | <annevk> | TabAtkins: dunno, twelve months or so |
| 16:02 | <annevk> | TabAtkins: we'd also need a new name for "Elements" |
| 16:02 | <TabAtkins> | Okay, that's reasonable. |
| 16:02 | <TabAtkins> | What do you mean? |
| 16:02 | <annevk> | TabAtkins: "Nodes" might work |
| 16:03 | <annevk> | TabAtkins: queryAll() returns an Array-subclass named Elements |
| 16:03 | <TabAtkins> | Oh! |
| 16:03 | <annevk> | TabAtkins: PsuedoElement is arguably an Element, but ShadowRoot is not |
| 16:03 | <TabAtkins> | Yeah, maybe. I mean, I'm not fussed about something called Elements containing instance of both Element and PseudoElement. |
| 16:03 | <TabAtkins> | Ah, true (though maybe it can WebIDL-implement PseudoElement). |
| 16:04 | <annevk> | Interesting idea |
| 16:04 | <annevk> | Okay, should be fine then I suppose if we can make that work |
| 16:05 | <TabAtkins> | (I think the PseudoElement generic interface will probably contain only two fields: name and originatingElement.) |
| 16:05 | <TabAtkins> | (Individual pseudos can subclass for more info, of course.) |
| 16:05 | <TabAtkins> | (Oh, and .style, obviously.) |
| 16:06 | <TabAtkins> | Okay, so plan of record is: |
| 16:06 | <TabAtkins> | Rephrase Selectors to be based directly on DOM, with a note about how non-DOM languages can map to a DOM. |
| 16:07 | <TabAtkins> | For the purpose of Selectors, augment DOM with arbitrary pseudo-elements as well. |
| 16:07 | <TabAtkins> | And, separately, define a PseudoElement interface people are willing to implement (in some other spec). |
| 16:08 | <annevk> | Sounds about right. Consider naming originatingElement ownerElement instead |
| 16:09 | <astearns> | TabAtkins: "something called Elements containing instance of both Element and PseudoElement" |
| 16:09 | <TabAtkins> | Ah, that works. |
| 16:09 | <astearns> | sounds a bit like the region interface, defined to be either an element or pseudoelement |
| 16:10 | <astearns> | might want to look at the discussion of why we got pushback on that |
| 16:10 | <TabAtkins> | "originating element" is just the language fantasai and I came up with, as a replacement for Hixie's "superior parent". |
| 16:10 | Ms2ger | wonders if this tree is going to be defined better than the box tree |
| 16:11 | <TabAtkins> | Ms2ger: DOM is indeed better defined than the box tree, yes. |
| 16:11 | <TabAtkins> | (And I'm still on the hook for the box tree - it goes in my spec.) |
| 16:11 | <TabAtkins> | astearns: Yeah, I plan to basically reopen that discussion. |
| 16:12 | <Ms2ger> | TabAtkins, I meant DOM+pseudos |
| 16:12 | <astearns> | TabAtkins: ok, just wanted to make sure you weren't blundering blindly into it :) |
| 16:12 | <TabAtkins> | Ms2ger: It's defined as "DOM, but with additional pseudos". ^_^ |
| 16:12 | <TabAtkins> | (Not really; I've got in mind what should be a decent definition.) |
| 16:18 | <annevk> | I think it's not too different from elements having flags for pseudo-classes |
| 16:18 | <annevk> | Flags for pseudo-classes, slots for pseudo-elements |
| 16:18 | <TabAtkins> | Yeah, exactly. |
| 16:18 | <TabAtkins> | Specialized information augments that are only visible while evaluating Selectors against the element. |
| 16:19 | <TabAtkins> | (Interestingly, the selectors data model is no longer a tree anyway - since the Scoping pseudo-elements, it's a DAG.) |
| 16:20 | <annevk> | DAG? |
| 16:20 | <MikeSmith> | what's the right way to programmatically determine the current date in the user's local time zone? |
| 16:20 | <TabAtkins> | annevk: directed acyclic graph |
| 16:20 | <annevk> | "Directed acyclic graph" |
| 16:20 | <TabAtkins> | There are multiple paths to a given element now. |
| 16:20 | <TabAtkins> | To some given elements, at least. |
| 16:21 | <annevk> | Only if you use ::shadow and only if you assume they are not distinct matching operations |
| 16:21 | <TabAtkins> | "foo > bar" and "foo::shadow ::content > bar" select the same element in "<foo><bar/><::shadow><content/></::shadow></foo>". |
| 16:24 | <annevk> | MikeSmith: you can get all the info from new Date() |
| 16:25 | <annevk> | MikeSmith: d = new Date(); alert(d.getYear() + " " + d.getMonth() ... |
| 16:25 | <annevk> | TabAtkins: oh man, those are pretty trippy |
| 16:26 | <annevk> | TabAtkins: that does look like what you'd want; good luck defining them ^_^ |
| 16:29 | <MikeSmith> | annevk: ok so if I then do d.getHours() that returns the local hour? |
| 16:29 | <annevk> | MikeSmith: it should |
| 16:29 | <MikeSmith> | ok |
| 16:30 | <zewt> | https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date |
| 16:30 | <annevk> | new Date().getHours() gives 18 for me which seems about right |
| 16:32 | <MikeSmith> | yeah, I assume it's defined that way. Otherwise there'd be no point to getUTCHours() |
| 16:32 | <MikeSmith> | I suppose I should actually read the spec |
| 16:33 | <annevk> | MikeSmith: well to be fair, there's no logic to the Date object really |
| 16:33 | <annevk> | MikeSmith: it's badly designed and I think people want to offer a better API as soon as there's modules |
| 16:33 | <MikeSmith> | that would be nice |
| 16:33 | <zewt> | one of the many warts of the platform: that the short "getHours" ones are local time and "UTC" is the one that looks special, instead of getHours being UTC and having local be getLocalHours |
| 16:36 | <MikeSmith> | zewt: yeah though it seems that's actually a wart of JS itself |
| 16:52 | <MikeSmith> | jsbell: Can you review pull requests for IDB tests? Or is there someone else who can? There's a bunch of tests waiting to be reviewed: https://github.com/w3c/web-platform-tests/pulls/yunxiaoxie |
| 16:53 | <jsbell> | MikeSmith: Zhiqiang has been doing it |
| 16:55 | <MikeSmith> | jsbell: ok |
| 16:56 | <zewt> | MikeSmith: warts of JS and warts of the platform are the same thing |
| 16:56 | <zewt> | as far as I'm concerned, heh |
| 17:24 | <Domenic_> | annevk: https://www.npmjs.org/package/dom4-elements |
| 17:24 | <Domenic_> | it doesn't absolutize relative selectors, which is kinda dumb. and the name makes me sad. |
| 17:24 | <Domenic_> | but, it's neat. |
| 17:25 | <annevk> | fun |
| 17:25 | <annevk> | Domenic_: did you see the backlog? TabAtkins is proposing some interesting additional features |
| 17:25 | <Domenic_> | annevk: I didn't see TabAtkins original proposal, but I saw the replies... |
| 17:25 | <TabAtkins> | Well, "features". |
| 17:26 | <annevk> | Well, pseudo-elements. |
| 17:26 | <TabAtkins> | Plan is to allow pseudo-elements to return PseudoElement objects in an Elements array. |
| 17:26 | <Domenic_> | Is PseudoElement a thing? |
| 17:26 | <TabAtkins> | Most direct use-case is to say "foo::shadow" to get the ShadowRoots of an element. |
| 17:26 | <TabAtkins> | Not yet, no. |
| 17:27 | <TabAtkins> | (astearns came up with a proposal earlier, but it died. I plan to revive it.) |
| 17:28 | <astearns> | TabAtkins: first convince abarth |
| 17:28 | <TabAtkins> | Sure. |
| 17:28 | <TabAtkins> | Easier to convince with more concrete use-cases now, like "foo::shadow". |
| 17:29 | <TabAtkins> | query("foo::shadow") rather than query("foo").map(function(el) { return el.shadowRoots; }) (or whatever). |
| 17:30 | <annevk> | queryAll* |
| 17:30 | <TabAtkins> | Yeah, sorry. |
| 17:53 | <Hixie> | TabAtkins: iirc, i had used "superior parent" rather than something with "element" in the name because it might not be an element (but i don't remember what this was about now, so it might no longer apply) |
| 17:53 | <TabAtkins> | Hixie: PsuedoElement is *like* an element. |
| 17:53 | <Hixie> | in some ways |
| 17:57 | <annevk> | TabAtkins: you could just stick with owner |
| 17:57 | <annevk> | TabAtkins: I guess in some setups it could be another Pseudo-Element |
| 18:02 | <Hixie> | "owner" has a lot of baggage |
| 18:03 | <dglazkov> | TabAtkins: I have a mental block. What's the value in display module to make element's box disappear? |
| 18:05 | <dglazkov> | display-box: contents |
| 18:08 | <TabAtkins> | annevk: Yes, it will probably be possible to be a pseudo element in the future. |
| 18:08 | <TabAtkins> | dglazkov: Yes |
| 18:08 | <dglazkov> | \o/ |
| 18:09 | <TabAtkins> | annevk: foo::before::before, for example |
| 18:09 | <SamB> | hmm, hmm, hmm ... |
| 18:11 | <SamB> | ... reference "element"? context "element"? |
| 18:12 | <Hixie> | "superior parent" :-) |
| 18:12 | <dglazkov> | Hixie: you called? :P |
| 18:13 | <dglazkov> | wait no, I am just "#1 dad" |
| 18:13 | <dglazkov> | that's what the mug says. it must be true |
| 18:14 | <Hixie> | Domenic_: btw, on the whatwg list, +1s (or "i strongly support this") don't have much meaning, especially if the +1 comes from someone with a horse in the race (like, "i strongly support that you use this feature i worked on") :-) |
| 18:16 | <SamB> | parent seems kind of confusing here wrt :before/:after ... |
| 18:16 | <Hixie> | why? |
| 18:16 | SamB | goes to see what it looks like in the DOM inspector ... |
| 18:16 | <Hixie> | ::before is a child of the element it's attached to |
| 18:16 | <Hixie> | ::before really means "before the content" |
| 18:16 | <Hixie> | or "just inside" |
| 18:16 | <SamB> | hmm, okay, so it's not as confusing as I was expecting |
| 18:17 | <TabAtkins> | SamB: Yeah, the naming is pretty unfortunate, but that's *long*-frozen legacy. |
| 18:17 | SamB | may be thinking of some other pseudo-element? |
| 18:18 | <TabAtkins> | ::firstest-child and ::lastest-child. |
| 18:19 | <Domenic_> | Hixie: sure, I wouldn't have written a message with that as the *only* content. It was more, before I criticize specifics, let me be clear I'm rooting for you. |
| 18:19 | <SamB> | yeah, I trust the old DOM inspector to know what it's doing here ... which may be crashing firefox ... |
| 18:20 | <Domenic_> | ::before::before rises again!!! I strongly support this! |
| 18:21 | <dglazkov> | always wondered if ::before is explained by the mysterious decorators |
| 18:22 | <SimonSapin> | and ::before(2)? |
| 18:24 | <TabAtkins> | SimonSapin: Sure, why not. It's distinct from ::before::before and useful for different things. |
| 18:25 | <TabAtkins> | Domenic_: We've finally removed the restrictions on things appearing on the RHS of a pseudo-element, so allowing more pseudo-elements there is the next logical step |
| 18:25 | <SimonSapin> | TabAtkins: do you know what’s happening with http://dev.w3.org/csswg/css-pseudo/ ? |
| 18:25 | <SimonSapin> | do people think it’s a bad idea, or is just that nobody has bothered yet to push it? |
| 18:26 | <TabAtkins> | SimonSapin: Latter. |
| 18:26 | <TabAtkins> | Once I'm done fixing up Selectors 4, I plan to pick up Pseudo to give it more love. |
| 18:26 | <SimonSapin> | cool |
| 18:41 | <Ms2ger> | TabAtkins, can you find a few more people like you? |
| 18:41 | <Ms2ger> | I wanted the box tree defined last year ;) |
| 18:42 | Ms2ger | wonders if TabAtkins has siblings |
| 18:45 | <TabAtkins> | Ms2ger: Man, I've been trying. |
| 18:45 | <TabAtkins> | And I do, but none of them are involved with the web. |
| 18:45 | <Ms2ger> | To get sibli... Oh |
| 18:46 | <jgraham> | Maybe to create more people genetically similar to himself? |
| 18:46 | <TabAtkins> | Getting siblings is no longer an option. |
| 18:46 | <TabAtkins> | Except through adoption, I suppose. |
| 19:32 | <astearns> | TabAtkins: SimonSapin there were definitely some people who thought css-pseudo was the worst idea in the world |
| 19:32 | <astearns> | which is the main reason I haven't been pushing it |
| 19:37 | <TabAtkins> | astearns: Obviously that's never stopped me. |
| 19:37 | <astearns> | :) |
| 19:37 | <SamB> | astearns: what do they prefer instead? XBL 1.0? |
| 19:38 | <astearns> | SamB: no alternative, just not my draft |
| 19:40 | <SamB> | Hixie: why do they need "superior parent" when they're basically just extra-document children? why not just "parent"? |
| 19:44 | <TabAtkins> | SamB: Because they're not children. |
| 19:44 | <TabAtkins> | "parent" implies that the opposite relationship is "child". |
| 19:44 | <SamB> | so pseudo-parent? |
| 19:45 | <TabAtkins> | But then that's just weird. |
| 20:20 | <zewt> | "xxx parent" referring to something that isn't the opposite of "child" is weird, too |
| 20:22 | <Hixie> | iirc "superior parent" reflected to "inferior child"? |
| 20:22 | <Hixie> | i could be wrong |
| 20:22 | <Hixie> | it's been a while |
| 20:22 | <SamB> | pseudo is a good word for weird things |
| 21:20 | <Hixie> | anyone remember when form controls were added to HTML browsers? |
| 21:23 | <tantek> | Hixie, Dave Raggett added forms and tables to HTML2 IIRC |
| 21:25 | <Hixie> | i wonder where that stood relative to implementations |
| 21:25 | <Hixie> | http://www.w3.org/People/Raggett/book4/ch02.html suggests april 1993 |
| 21:26 | <tantek> | back when browsers and mailing lists were tightly bound |
| 21:27 | <Hixie> | next question, when did mobile safari come out? june 2007? |
| 21:27 | <tantek> | i.e. anyone could suggest something, implementer or w3c person, and if it seemed like a good idea it just got built/deployed |
| 21:27 | <Hixie> | same as now then? ;-) |
| 21:27 | <tantek> | Hixie - took us a while to get back here |
| 21:27 | <Hixie> | true dat |
| 21:27 | <SamB> | so why we no can has MNG again? |
| 21:28 | <tantek> | SamB - comment on the bug(s) in bugzilla ;) |
| 21:28 | <SamB> | noooooo |
| 21:28 | <gsnedders> | Hixie: mob saf was same time as iPhone shipped, so would be then |
| 21:28 | <tantek> | lol |
| 21:28 | <SamB> | actually I might have done that |
| 21:28 | <SamB> | but, um, it's not likely to help ... |
| 21:29 | <tantek> | SamB, works for some browsers sometimes |
| 21:30 | <SamB> | actually, more seriously, JNG seems a shame to lose just because MNG got ripped out ... |
| 21:36 | <SamB> | tantek: iirc, it looked like there was either (a) an irrational hatred for MNG/mnglib or (b) an inadequately explained, but rational, hatred for MNG/mnglib |
| 21:37 | <tantek> | like RDF hatred or something else? |
| 21:37 | <SamB> | at https://bugzilla.mozilla.org/show_bug.cgi?id=mng |
| 21:37 | <SamB> | well, RDF is kind of crazy syntax-wise |
| 21:37 | <SamB> | I can understand why people might hate that |
| 21:39 | <Hixie> | MNG is waaaay over-engineered |
| 21:39 | <SamB> | Hixie: yeah, hence the "more seriously, JNG [...]" |
| 21:40 | SamB | wishes the MNG people weren't such sore losers ... |
| 21:46 | <Hixie> | yeah i often wonder about that kind of reaction |
| 21:47 | <Hixie> | e.g. i wonder if people realise how many specs or parts of specs i've worked on (or that many others in this channel have worked on) that have gone down the drain |
| 21:47 | <Hixie> | some involving years and years of work |
| 21:47 | <Hixie> | e.g. xbl2, web sql db |
| 21:47 | <Hixie> | web controls 2.0 |
| 21:47 | <Hixie> | you can't take it personally |
| 21:48 | <SimonSapin> | astearns: "people who thought css-pseudo was the worst idea in the world", did they give any reason? |
| 21:53 | <zewt> | if someone doesn't make a reasonable lightweight animation format to replace gif, one of these days someone's just going to hack RGBA32 into GIF and it'll catch on and then we'll be stuck with that for all eternity |
| 21:56 | <astearns> | SimonSapin: some are in the minutes: http://lists.w3.org/Archives/Public/www-style/2012Aug/0771.html |
| 21:57 | <astearns> | SimonSapin: mainly they thought the use cases were something we should not design a CSS feature for |
| 21:58 | <tantek> | Hixie - perhaps when people spend years only working on a single spec |
| 21:58 | <tantek> | then their emotional vesting is all in one basket |
| 22:01 | <Hixie> | oh faff, the w3c want me to change my password to a more "secure" one |
| 22:01 | <Hixie> | like i care one bit if that account can be compromised |
| 22:01 | <Hixie> | now i'll always be forgetting the password |
| 22:05 | <smola> | Hixie: just change it to H1x13<year><month> every month, military-grade password policy compliant ;) |
| 22:39 | <Hixie> | yay, w3c is actively forking canvas: http://www.w3.org/mid/53515EA3.7090205⊙wo |
| 22:42 | <tantek> | ugh |
| 23:05 | <zewt> | i'm officially declaring document.cookie The Worst Web Platform API |
| 23:06 | <SamB> | zewt: it did look pretty bad ... |
| 23:06 | <SamB> | I mean is that even an API? |
| 23:06 | <zewt> | the fact that you can't even take the value of document.cookie, and assign it to document.cookie, and have it do the obvious thing... |
| 23:14 | <Hixie> | document.cookie is pretty terrible. |
| 23:14 | <Hixie> | the race condition is my favourite part of it. |