2014-09-01 [19:31:47.0000] hey there folks, is there any info on why there are html5 specs on whatwg and 5.1 on w3c and the relation between them? [19:50:32.0000] w3c wants their specs to look newer, so they use a bigger number [20:23:12.0000] jxs: here is some information about that: http://www.w3.org/html/landscape/ [20:26:20.0000] thanks :) [22:05:14.0000] Hixie: I think the HTML spec should explicitly disallow comments in the media attribute [22:05:27.0000] If you want, I can file a bug for it [22:06:09.0000] or come to think of it maybe I already did (at least I know I did for sizes) [22:09:20.0000] Hixie: and to be clear I mean the document-conformance criteria [22:11:21.0000] there's no good reason for Web developers to put CSS comments into attribute values [22:12:10.0000] but if/when some developers find out they're allowed, they'll start putting some in just because they can [23:52:20.0000] MikeSmith: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26195 [00:44:37.0000] annevk: various github.io things get CSS blocked as mixed content for me [00:44:54.0000] annevk: not exactly a run-of-the-mill FOUC [00:57:26.0000] hsivonen: annevk the http://sideshowbarker.github.io/console-spec/ FOUC is just due to respec I think [00:58:16.0000] zcorpan: ah ok thanks (/me is not caught up on e-mail) [00:59:50.0000] I guess my answer to the question "what's the value of disallowing them?" is "what's the value in allowing them?" [01:00:06.0000] an HTML attribute value is not a CSS stylesheet [01:03:25.0000] MikeSmith, annevk: Maybe https everywhere rewrites github.io to https for me [01:03:58.0000] MikeSmith: and yes, it seems more plausible that the non-http FOUC would be respec than Gecko [01:04:29.0000] hsivonen: oh yeah, it's definitely respec; I just meant to point out it still exists [01:04:48.0000] hsivonen: seems that HTTPS Everywhere is doing that for you [01:05:25.0000] does html5lib have tests for https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 yet? [01:06:03.0000] annevk: that sort of existence is quite a bit different than the sort of existence I meant [01:10:32.0000] hsivonen: https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/tests9.dat#L34 maybe? [01:10:58.0000] [01:13:17.0000] MikeSmith: that's a full doc [01:13:23.0000] /me wonders if gsnedders and jgraham__ think that the html5lib test files having names like tests9.dat is any better than bad 001.html naming convention [01:13:25.0000] MikeSmith: looking for fragment parsing tests [01:13:28.0000] hsivonen: ah yeah [01:15:22.0000] hsivonen: grepping through the tests localy I find probably there are none [01:42:24.0000] hsivonen: wanna drop parsing in gecko? [01:57:48.0000] zcorpan: great success: http://www.chromestatus.com/metrics/feature/timeline/popularity/426 [01:57:59.0000] your move [01:58:19.0000] foolip: thanks! [01:58:36.0000] foolip: it's data from stable i assume? [01:58:42.0000] zcorpan: yes, it was in M37 [01:58:50.0000] it would have moved by now if it was going to [01:59:02.0000] but it may just rise to something like 0.0001% in the coming week [01:59:12.0000] in any event, ~0 [01:59:38.0000] this is what another M36 counter looks like: http://www.chromestatus.com/metrics/feature/timeline/popularity/427 [02:00:41.0000] foolip: what does the @charset counter look for again? [02:02:42.0000] zcorpan: CSSCharsetRuleEncoding counts any read or write to CSSCharsetRule.encoding [02:03:21.0000] it doesn't directly prove that removing the entire CSSCharsetRule is safe, but makes it seem plausible [02:06:27.0000] the problematic bit is likely sites doing indexed access to other rules [02:08:32.0000] i can look into the spec side of this next week [02:14:02.0000] zcorpan: yep, that's the risky bit, and with no good way of measuring AFAICT [02:15:37.0000] yeah [02:55:45.0000] zcorpan, r? https://critic.hoppipolla.co.uk/r/2485 [02:57:01.0000] Ms2ger: done [02:57:16.0000] Ta [02:59:04.0000] http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0002.html lol [02:59:58.0000] TL;DR sounds like "I didn't read the email I replied to" [03:02:52.0000] MikeSmith, if you have better names for tests#.dat... ;) [03:04:01.0000] math-svg.dat [03:04:16.0000] Well, sure [03:04:23.0000] But they're not all that clear-cut [03:04:29.0000] sure [03:12:15.0000] Yeah, the tests-*.dat aren't grouped in any particular way so in general it's hard to name them. I think the first is the real problem [03:22:14.0000] your license doesn't say i can't put dogshit on your doormat [03:35:11.0000] Yeah, I wonder if people are guenuinely unable to understand the difference between the spirit and the letter of a license or if they're just being disingenuous [04:05:13.0000] jgraham: I think neither. I think they've rationalized it because they don't want to think of themselves as people who do hostile, hypocritical things. Therefore because they're good people, what they're doing can't actually be bad. [04:05:51.0000] there must be some clinical term for that kind of thinking [04:06:29.0000] in other news, "Nicholas Cage is no replacement for kittens" [04:41:03.0000] should I be reading public-w3process? [04:41:49.0000] gmail decided to land that thread (that annevk linked to above) in my inbox despite my filters saying it belongs under W3C [05:19:00.0000] I'm so behind the times that my html5lib checkout has a .hg directory :-( [05:21:12.0000] zcorpan: I don't see dropping as a particular win at this time [05:21:33.0000] though it's kinda sad that it's one more thing the Tor Browser Bundle folks need to worry about [05:22:33.0000] hsivonen: ok. yeah i don't disagree [05:23:48.0000] I don't dare to just review that SVG innerHTML stuff by reading the patch [05:23:54.0000] time to write some tests [05:24:19.0000] MikeSmith: well the html5lib tests don't have any meaningful division, so while the tests could do with being rearranged it's not really high priority [05:24:46.0000] MikeSmith: and it means files can't just be renamed [05:25:11.0000] hsivonen, sounds like a good outcome :) [05:26:26.0000] looks like Blink doesn't actually have code for http://html5.org/tools/web-apps-tracker?from=7917&to=7918 [05:26:37.0000] at least I'm not the only one failing to track the spec [05:28:05.0000] :/ [05:28:41.0000] I've thought about having a bot just file a "write a test for this" for every changeset [05:28:55.0000] Somewhere a long way down on my to-do list is writing test cases for all changes to the parser [05:30:55.0000] where does blink deal with putting the innerHTML of SVG elements into the SVG namespace? [05:40:24.0000] https://chromium.googlesource.com/chromium/blink/+/a8a0a83498e1d5f7014c79cffa7e45fda6a8b08a%5E!/#F18 [05:42:31.0000] I'm unamused by http://html5.org/tools/web-apps-tracker?from=7767&to=7768 . Clearly, I've had the parser swapped out for too long. [05:48:07.0000] I was about to complain that the Blink developer didn't add html5lib tests for that changeset and then I realized the html5lib test format's existing harnesses probably don't support non-HTML context elements [05:52:16.0000] hsivonen: we should probably just support the svg:foo syntax there, I guess [05:52:44.0000] hsivonen: there's also a lot of blink html5lib tests that need upstreamed, but it's a bit ambiguous as to license in the Blink (and WebKit) repo so I don't want to just grab them myself [05:54:27.0000] context element is the #document-fragment in https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/tests_innerHTML_1.dat ? [05:54:36.0000] yeah [05:56:22.0000] gsnedders: isn't it better to use a space like in the expected output? [05:56:48.0000] zcorpan: I was meanaing the same as the expected output, just misremembering what that was :) [05:56:54.0000] ah [05:57:20.0000] /me is on pretty poor on-train wifi [06:13:53.0000] annevk: fun times in the "[Encoding] false statement" thread [06:17:32.0000] hsivonen: link? [06:17:50.0000] foolip: http://lists.w3.org/Archives/Public/www-international/2014JulSep/ [06:18:16.0000] hsivonen: thanks! [06:23:05.0000] I don't understand how annevk has the energy for participating in these kinds of discussions [06:29:31.0000] foolip: cute baby helps [06:29:45.0000] :) [07:35:57.0000] annevk: is implementation of the URL spec in blink stalled on something? [07:36:22.0000] I see https://code.google.com/p/chromium/issues/detail?id=303152 with no updates for more than 2 months [07:37:40.0000] and https://codereview.chromium.org/143313002/ waiting on action from sof? or review? [07:42:12.0000] MikeSmith: wouldn't it be better to ask arv? [07:44:46.0000] smaug____: I can't tell from chromium bug tracker and review tool who's the assignee, reviewer [07:46:15.0000] the UI of that stuff seems to be some kind of (reverse) intelligence test [09:20:44.0000] MikeSmith: there's many different parts of the URL spec [09:21:35.0000] But e.g. new URL("test:test") works in dev [10:53:45.0000] HTML spec's attribute handling is so hard to follow [10:54:42.0000] "Each input, select, and textarea element has an autofill hint set, an autofill scope, an autofill field name, and an IDL-exposed autofill value." but then..."The subsections that define each type also clearly define in normative "bookkeeping" sections which of these feature apply, and which do not apply, to each type." [10:55:10.0000] and "autocomplete" doesn't apply to type="hidden" [10:55:43.0000] Hixie: ^ [10:56:53.0000] ahaa, "When an attribute doesn't apply to an input element, user agents must ignore the attribute, regardless of the requirements and definitions below." [10:56:59.0000] yes? [10:56:59.0000] almost unreadable spec [10:57:05.0000] file bugs [10:57:06.0000] but nothing new there :) [10:58:43.0000] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 may be of relevance for the specific case you are referring to, btw [10:58:57.0000] i'm half-way through the relevant edit [10:59:06.0000] (it's unlikely to make the spec any clearer though) [11:45:56.0000] Hixie: with DreamHost VPS do you still have their control panel or is it very low-level? [11:46:19.0000] I'm somewhat curious whether I should get a VPS somewhere so I have more low-level control [11:46:21.0000] yes, it's identical except you get an additional control for how much extra money to give them, essentially [11:46:26.0000] and you get root [11:46:43.0000] (the control is really about how much RAM to reserve) 2014-09-02 [18:38:12.0000] Just stumbled upon performance and performance.now [18:39:36.0000] Is there yet something like requestAnimationFrame that lets me specify a frame rate that will attempt to correct itself? Ala http://www.andrewduthie.com/post/a-self-correcting-setinterval-alternative/ [22:59:42.0000] /me reads http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0002.html per annevk bringing it up here, also lol, and adds it to the collection of things to bring up to the AB [23:52:48.0000] maybe https://twitter.com/zcorpan/status/506695939982376960 illustrates why json in an attribute has problems https://twitter.com/zcorpan/status/506695939982376960 [00:15:46.0000] To: Ms. Anne Kesteren, Editor, and associates [00:24:42.0000] hihi [00:25:16.0000] why not mrs? they did the research? [02:01:26.0000] marcosc_: "Just because you can stab someone with a kitchen knife in the face doesn't mean you should. [02:03:20.0000] I'm pretty both the letter and the spirit of the law is to disallow that [02:06:51.0000] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#read-html "After creating the Document object…" on navigation, why do we create the new document before unloading the old one? [02:19:10.0000] Presumably for more seamless transitions [02:28:16.0000] annevk: means we can't activate a serviceworker script between navigations [02:28:33.0000] wait why not? [02:29:10.0000] Because if the new doc overlaps with the old one, there's no point the old serviceworker script isn't in use [03:04:17.0000] odinho: Ms is more neutral than Mrs [03:05:46.0000] And yes, it does seem like there are more obvious examples of complying with the letter, but not the spirit, of the law than stabbing someone in the face [03:05:52.0000] Tax evasion, perhaps [03:21:01.0000] jgraham: I thought tax evasion was illegal too - maybe you mean tax avoidance? [03:21:44.0000] Good point [03:22:13.0000] /me prefers to just run headlong into tax [03:22:44.0000] I hear some people find your energentic approach too taxing [03:22:59.0000] *energetic [04:57:13.0000] i don't like it that people spend annevk's time on editorial fluff [04:58:41.0000] Could be arguing about how to write unicode code points... [04:59:34.0000] Ms2ger: at least that's terminology used in normative parts [05:56:25.0000] how about we use fetch-* that can be converted into JSON by like this -> {"priority":{"dependency":{"id":"i1"}, "weight":"8"}} [06:36:55.0000] So am I crazy in thinking ARIA is supposed to be an abstraction layer on top of native accessibility APIs? e.g. as in http://lists.w3.org/Archives/Public/public-html/2014Sep/0003.html [06:38:06.0000] ... crazy ... public-html ... [06:38:10.0000] Sounds right [06:42:09.0000] indeed :-S [06:53:43.0000] Domenic: it doesn't sound crazy, but i don't know about the details [07:02:22.0000] Domenic: what zcorpan_ said [07:03:03.0000] Domenic: I don't understand myself why it's not actually defined that way [07:04:27.0000] /me kind of assumed it was defined that way [07:05:15.0000] Domenic: I wanted the accessibility tree exposed. [07:06:08.0000] tobie: what does that mean, exactly... [07:06:52.0000] Domenic: but I can say from experience that among bad side effects it has is that when you contribute tests to a browser project for a Web-platform feature that affects how Web content ends up getting exposed to accessiblity software, you have to write tests that are completely platform-specific, and that rely on building and using special testing tools that run outside the browser binary [07:07:18.0000] jgraham: it's not defined as such in any kind of testable way [07:07:51.0000] if there is any such abstraction, it's an abstract abstraction -- an untestable abstraction [07:07:52.0000] MikeSmith: right, this would not be the case if an accessibility tree was agreed-upon and tested. [07:08:19.0000] MikeSmith: it depends precisely what you want to test though. [07:08:21.0000] tobie: right and I myself don't understand why it's not what way [07:09:06.0000] MikeSmith: my understanding is players in the field don't want standardization at that level [07:09:14.0000] really? [07:09:30.0000] I hadn't heard that at least [07:10:36.0000] I think SteveF at least has been advocating for an actually useful abstraction layer to be defined -- one that's exposed to JS and testable [07:11:00.0000] yes please. [07:15:08.0000] Domenic: ~ same as the DOM but for Aria roles. [07:15:38.0000] Domenic: at least that's how I understand it. [07:28:46.0000] Domenic: suggest talking to Dominic Mazzoni at Google or pop into the irc://irc.mozilla.org/accessibility and talk to Dave bolter or Marco Zehe or alex surkov (to name a few) they all work on implementation side [07:37:06.0000] Thanks SteveF [07:37:11.0000] zcorpan: According to my experience, adding open-ended attributes is just playing twisted games with the web for my own amusement. [07:38:34.0000] TabAtkins: elaborate? [07:38:48.0000] The attempt to do src-n. ^_^ [07:40:51.0000] ah [07:41:16.0000] MikeSmith: Disallowing comments in media requires a special switch in the CSS parser for no good reason, and forks syntax. [07:42:08.0000] Comments are only an added difficulty if you're writing your own custom CSS "parser" that doesn't attempt to be complete or actually follow the Syntax spec. [07:42:19.0000] In Syntax it's just a few lines of code to handle them. [07:42:26.0000] I'm not writing a CSS parser at all [07:42:28.0000] TabAtkins, no [07:42:40.0000] I don't need to write a parser [07:42:43.0000] TabAtkins, UA conformance != author conformance [07:43:25.0000] Ms2ger: Sure. I'm not clear on whether MikeSmith is advocating just a user-conformance restriction or not. [07:43:44.0000] The logs seemed quite clear on yes [07:44:05.0000] I'm reading backwards, and hadn't read the entire thing yet. [07:45:53.0000] Should anyone be concerned? This seems like a sad thing. http://arstechnica.com/information-technology/2014/08/google-to-drop-microsoft-designed-touch-web-spec-stick-with-apple-tech/ [07:46:34.0000] No. [07:47:10.0000] SteveF: is there a document like http://rawgit.com/w3c/aria/master/html-aam/html-aam.html that maps ARIA roles/etc. to platform accessibility stuff, instead of mapping HTML to platform accessibility stuff? [07:47:11.0000] It's an attempt to converge, it was discussed in a meeting with all browsers. MS isn't quite ready to drop pointer events yet, but we'll see. [07:48:58.0000] TabAtkins: is there a desire by implementers to normalize events? If so, where is the traction these days; touch events? [07:49:29.0000] Yeah, the hope is to have everything settle into one type of input-device-neutral event. [07:51:31.0000] I was developing for a touch TV last week and handing off my work to other devs. I normalized all the touch/mouse/pointer events into pointer events, figuring that, by now, it was settled as the future. [07:51:40.0000] TabAtkins: right now I'm just advocating for a document-conformance ban (aka authoring conformance), on CSS comments in HTML attributes (@sizes & @media) [07:51:45.0000] Not a big deal to normalize them to some other convention, but still kind of a bummer. [07:52:28.0000] MikeSmith: I'm just with Hixie on this - I don't understand why they're bad. [07:52:43.0000] Domenic: my understanding it that's precisely the part there's no agreement to standardize. [07:52:59.0000] Domenic: core mappings http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html SVG mappings http://rawgit.com/w3c/aria/master/svg/svg-implementation.html [07:53:57.0000] My understanding is obviously completely incorrect. [07:54:22.0000] SteveF: nice. So my job ... if I choose to go that route, which I am unsure on ... is to diff the capabilities provided by the latter with the the ones HTML uses, and get implementer buy-in to fill in the gaps. [07:58:37.0000] domenic: sounds about right note gaps include html specific accessible name calculation http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation which is not covered in ARIA also note the svg and html acc specs are very much work in progress, and the core mappings will also be changing as language specific stuff gets moved out [07:59:27.0000] SteveF: cool... the accessible name calculation thing is also important to note. [08:01:17.0000] Domenic: the html name calc has never been defined until i started to test and document and talk with implementers (still much to do on that) which unsurprisingly resulted in interop issues [08:04:49.0000] SteveF: awesome, this is real hard-core archeology work you are doing... [08:09:28.0000] TabAtkins: outside of the document-conformance part I'm not sure why you have a hard time understanding why I'm not happy about needing to write and maintain and bugfix several hundred lines of code to implement a full CSS tokenizer when I'm not implementing a CSS parser nor processing CSS stylesheets but instead only want to help authors catch mistakes in one single HTML attribute value [08:09:40.0000] in other words, overkill [08:09:49.0000] in yet other words, code bloat [08:12:28.0000] MikeSmith: To properly parse an MQ, you have to implement most of Syntax already. And if you have a hacked-up parser, it's not hard to do a pre-pass to find and eliminate comments from the value, since they don't nest or do anything tricky. It's literally something like str.replace(/\/\*.*?\*\//g, ""). [08:21:22.0000] TabAtkins: yeah in fact that pre-pass to just get rid of the comments is pretty much what I ended up doing. And it seems to working fine. I just get a little exhasperated sometimes with you continuing to tell me you don't understand why I don't deal with comments by writing a full CSS tokenizer, which is trivial to implement, etc. (if I just read and follow N different CSS specs) [08:22:46.0000] btw I think the way the microsyntax for @sizes is currently defined for authors in the HTML spec -- by referencing a CSS spec that references several other specs is also not exactly optimal either [08:23:39.0000] if i reference other specs, people complain it makes it hard to read. if i don't, people complain i'm making up new things instead of reusing existing things. [08:23:42.0000] i'm doomed either way. [08:24:39.0000] wait wait hold on [08:24:45.0000] do you mean or something else [08:24:57.0000] oh you mean the sizes [08:25:26.0000] blimey, yeah, that's quite the syntax right there [08:25:36.0000] i vote we don't support that use case natively [08:25:39.0000] do it with web components [08:28:00.0000] MikeSmith: A CSS parser is exactly one spec - Syntax. The definitions of various things, like , are in other specs, but parsing is localized. [08:28:44.0000] TabAtkins: Presumably authors care about things like length [08:32:18.0000] jgraham: MikeSmith already has to care about those. He's complaining about correct parsing, though, which is located entirely in one spec. [08:32:34.0000] (As long as you're not trying to parse a selector, which hasn't yet been updated away from the 2.1 grammar.) [08:32:43.0000] (But he's not, as selectors dont' appear in MQs.) [08:34:35.0000] Hixie: Luckily we routed around you, because "just use Javascript" isn't an acceptable answer for that use-case. [08:34:45.0000] "luckily" [08:34:54.0000] you routed the web into a ditch imho :-) [08:36:09.0000] You're free to feel that; you also don't build responsive sites with variable-width images. [08:37:05.0000] not everything that someone does is something that should end up in the spec [08:37:11.0000] as people keep telling me :-) [08:37:20.0000] Well, but this one thing is huge. [08:37:26.0000] huge is right [08:38:10.0000] I will probably start up again a magazine website I was creating that I put on ice since that part of the site was so tricky. Now it is simple :) [08:38:19.0000] (just so we're clear, i'm ok with supporting responsive images. i just think is a terrible design.) [08:38:39.0000] "simple" [08:39:44.0000] The srcset syntax is much larger than the sizes syntax (because it's custom, while sizes is just a fairly simple syntax definition). [08:40:09.0000] /me pats TabAtkins on the head [08:40:12.0000] (The algo required for sizes parsing is just for forwards-compat, so we can fail on any one entry without accidentally invalidating the entire attribute for not matching the grammar.) [08:40:29.0000] this is all moot, since y'all are doing this anyway [08:40:58.0000] but just because i've given up arguing doesn't mean i think it's right :-) [08:41:10.0000] Hixie, HTMLWG would disagree [08:41:19.0000] I find it easier to convince myself whatever decision was taken was right, unless I plan on correcting it in the future. [08:41:38.0000] TabAtkins: wow [08:41:45.0000] TabAtkins: that way lies madness [08:41:54.0000] Nah, I've got the escape-hatch. [08:41:59.0000] "lies" is a good choice of word [08:42:06.0000] But more importantly, I've got better things to care about most of the time. [08:42:16.0000] TabAtkins: there are plenty of things on the web that can never be changed that are nonetheless dumb [08:42:21.0000] TabAtkins: e.g. "Referer:" [08:42:33.0000] "right" includes "eh, don't care". [08:43:38.0000] i think it's better to keep caring and keep thinking its wrong, so that the next time something comes along and someone says "hey, let's copy this existing solution", you can say "no, that solution was dumb" [08:43:54.0000] e.g. the way that when someone wanted to copy the