| 08:55 | <zcorpan> | mathiasbynens: feel free to merge on wpt if you have reviewed and the comments are addressed |
| 09:19 | <zcorpan> | Hixie: would have been nice if svg style was scoped, but it's not afaict |
| 09:22 | <ondras> | dammit |
| 09:22 | <ondras> | https://bugzilla.mozilla.org/show_bug.cgi?id=169521 |
| 09:22 | <ondras> | all other browsers are doing the same |
| 09:22 | <ondras> | so probably a PEBKAC? |
| 09:23 | <ondras> | can please someone more skilled with xml confirm and/or explain? |
| 09:25 | <zcorpan> | ondras: it's a bug in the serializer |
| 09:28 | <zcorpan> | ondras: the xml parser normalizes a few literal characters in attribute values to U+0020 |
| 09:28 | <zcorpan> | ondras: so the xml serializer needs to escape them for proper round-tripping |
| 09:29 | <zcorpan> | ondras: HTML has the same deal for U+000D |
| 09:31 | <ondras> | zcorpan: yes, I would say I am pretty familiarized with how it works and how it *should* work |
| 09:31 | <ondras> | zcorpan: but the serializer does the same in all browsers; a behavior that often signifies a user error |
| 09:31 | <ondras> | zcorpan: also, this bug is 12 years old, so I would guess nobody really considers it a bug then? |
| 09:32 | <zcorpan> | ondras: ah. well in this case it's not a user error :-) |
| 09:32 | <Ms2ger> | ondras, just not one that's more important than the million other things that need fixing :) |
| 09:33 | <ondras> | Ms2ger: would be nice to at least acknowledge it is an issue :-) that would, for instance, motivate me to submit it to other browsers as well... |
| 09:34 | <Ms2ger> | zcorpan, can you please say "this is a bug" in the bug? ;) |
| 09:34 | <ondras> | :-) |
| 09:35 | <zcorpan> | didn't bz confirm it in 2002? |
| 09:36 | <zcorpan> | (maybe we don't want to escape U+000D though) |
| 09:36 | zcorpan | 101 switching trains |
| 09:36 | <ondras> | not sure what are all the relevant status keywords/states, but "NEW" is what I often see on new, raw, wait-with-focusing-on-that-till-more-input-or-money-is-provided issues |
| 09:56 | <zcorpan> | ok commented |
| 09:57 | <ondras> | zcorpan: thanks! |
| 09:57 | <annevk> | ondras: NEW means confirmed |
| 09:58 | <annevk> | ondras: UNCONFIRMED is when it's not acknowledged |
| 09:58 | <annevk> | ondras: at least for bmo |
| 09:59 | <zcorpan> | ondras: fwiw Presto passes the test |
| 09:59 | <ondras> | zcorpan: nice, I did not try that. just ff/chrome/opera. my bad. |
| 09:59 | <ondras> | ("new" opera, webkit/blink) |
| 10:00 | <zcorpan> | i don't expect people to test presto these days :-) |
| 10:00 | <ondras> | yeah. |
| 10:00 | <ondras> | let's try trident then .) |
| 10:01 | <zcorpan> | although createDocument threw an exception, adding another argument fixed it |
| 10:04 | <ondras> | yes |
| 10:04 | <ondras> | and the results are, hmm, different. |
| 10:04 | <ondras> | :) |
| 10:05 | <ondras> | but serializes properly it seems |
| 10:12 | <annevk> | ondras: does https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html define the behavior properly? |
| 10:18 | <ondras> | annevk: first of all, when using DOMParser with "text/html", the literal newline in attribute value seems to be preserved |
| 10:18 | <ondras> | annevk: which leads me to conclusion that text/html is treated in a different way than application/xml, with respect to parsing |
| 10:19 | <ondras> | annevk: and thus I would expect the option to choose beween these (two?) modes during the serialization |
| 10:23 | <Domenic> | annevk: if geolocation were to be deprecated for insecure origins, are mixed-content https pages insecure or secure? |
| 10:31 | <ondras> | annevk: I would say that the behavior matches https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#dfn-concept-serialize-attr-value , but this spec is not sufficient for serialization of generic XML documents |
| 10:34 | <ondras> | An XML parser, for the purposes of this specification, is a construct that follows the rules given in the XML specification to map a string of bytes or characters into a Document object. |
| 10:34 | <ondras> | At the time of writing, no such rules actually exist. |
| 10:34 | <ondras> | heh |
| 10:41 | <annevk> | Domenic: you'll have to define mixed content |
| 10:41 | <Domenic> | annevk: would the definition change the answer? |
| 10:42 | <annevk> | Domenic: if the mixed content is blocked, it's still secure |
| 10:42 | <annevk> | Domenic: if it's actually loaded, not so much |
| 10:42 | <Domenic> | annevk: hmm so if there is a loaded http:// <img>, the origin is no longer considered secure? |
| 10:52 | <annevk> | Domenic: apparently that's not considered mixed content just yet |
| 10:53 | <annevk> | Domenic: though it probably should |
| 10:53 | <annevk> | and is in Firefox Nightly |
| 10:53 | <annevk> | though only UI-wise, we don't actually block the loading |
| 10:53 | <annevk> | so I doubt that'd impact authenticated origin |
| 11:08 | <annevk> | https://blog.cloudflare.com/introducing-universal-ssl/ |
| 11:08 | <annevk> | Well, SSL for free |
| 11:08 | <annevk> | and easy too |
| 11:14 | <Domenic> | ... that page has mixed content |
| 11:14 | <Domenic> | terinjokes ^ |
| 11:16 | <Domenic> | including wildcards, wow |
| 11:17 | <jgraham> | Yeah |
| 11:20 | <jgraham> | Their map is super-surprising. It's really not obvious to me why Madagascar and Somalia would have as many modern browsers as Finland, but Ethiopia, say, would have far fewer. |
| 11:20 | <jgraham> | Latvia als looks like a hige outlier in Eastern Europe and Indonesia in the Far East |
| 11:21 | <jgraham> | *huge |
| 11:29 | <annevk> | Domenic: yeah mixed content is sad |
| 11:29 | <annevk> | but announcement is huge and awesome |
| 11:42 | <terinjokes> | Domenic: i don't have a tile server that isn't https (nor did I create the map on an https server… ah development) |
| 11:58 | <terinjokes> | Domenic: fixed, thanks |
| 11:59 | <terinjokes> | annevk: such sadness… i'll have to get all those tile servers to sign up :P |
| 12:06 | <zcorpan> | ondras: yep the html parser doesn't normalize LF or tab in attributes |
| 12:08 | <ondras> | zcorpan: sounds consistent with the serialization behavior. I would suggest adding xml serialization mode then. |
| 12:08 | <ondras> | (as parsing application/xml already works as expected) |
| 12:08 | <zcorpan> | ondras: there is an xml serialization mode already :-) |
| 12:09 | <ondras> | zcorpan: is there a secret "on" switch hidden somewhere? :) |
| 12:11 | <zcorpan> | ondras: XMLSerializer should always give you the xml serialization |
| 12:12 | <zcorpan> | ondras: innerHTML should give the xml serialization if the "node document" is an "XML document" |
| 12:12 | <Ms2ger> | [probably] |
| 12:16 | <zcorpan> | i'll file a bug on https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#dfn-concept-serialize-attr-value |
| 12:20 | <ondras> | zcorpan: okay, *should*, right :) |
| 12:20 | <ondras> | zcorpan: I will file a chrome issue then |
| 12:20 | <zcorpan> | ondras: well "must" per spec |
| 12:21 | <zcorpan> | ondras: i'm not using RFC2119 in irc :-) |
| 12:21 | <ondras> | :) |
| 12:21 | <ondras> | no offense, I was pointing to the fact that most browsers are not compliant with respect to this |
| 12:21 | <zcorpan> | any opinion on hex escape vs decimal escape? |
| 12:22 | <ondras> | I treat them equally |
| 12:22 | <zcorpan> | we need to decide what to spec |
| 12:22 | <ondras> | well the XML parsing spec uses #xA |
| 12:22 | <ondras> | so hex |
| 12:23 | <zcorpan> | ok https://www.w3.org/Bugs/Public/show_bug.cgi?id=26928 |
| 12:24 | <ondras> | zcorpan: cool, thanks! |
| 13:20 | <zcorpan> | Hixie: the innerHTML view in live dom viewer also explains the unnecessary vertical scrolling which is even more annoying than horizontal scrolling |
| 13:35 | <SimonSapin> | In practice, JS strings are neither UTF-16 (which disallows unpaired surrogates) nor UCS-2 (which is BMP only) but kind of a mix where surrogate pairs represent a supplementary code point but unpaired surrogates are also allowed. Is there a name for this? If not, what could we call it? |
| 13:36 | <Ms2ger> | Wait, it isn't ucs-2? |
| 13:36 | <Ms2ger> | Lovely |
| 13:37 | <SimonSapin> | in a way, it’s UCS-2 which we give a different meaning to when rendering text |
| 13:38 | <SimonSapin> | The definitions of UCS-2 I can find say it can only encode BMP code points |
| 13:47 | <jgraham> | SimonSapin: WTF-JS? :p |
| 13:48 | <SimonSapin> | it’s not just JS, though |
| 13:49 | <SimonSapin> | (I wish it was!) |
| 13:50 | <jgraham> | I guess if you are coining WTF-8, this is somewhat logically WTF-16? |
| 13:51 | <jgraham> | Also, it seems my serious suggestion and my not serious suggestion are distressingly close together |
| 13:52 | <darobin> | hehe |
| 14:44 | <annevk> | SimonSapin: JS is simply 16-bit integers |
| 14:45 | <annevk> | SimonSapin: it's the text layer that's special |
| 14:45 | <annevk> | SimonSapin: if anything |
| 14:45 | <SimonSapin> | annevk: yes, but we give meaning to these integers when rendering as text, and when decoding bytes from the network |
| 14:45 | <annevk> | SimonSapin: but those are different subsystems |
| 14:48 | <SimonSapin> | annevk: they’re the subsystems I’m interested in right now |
| 14:48 | <annevk> | SimonSapin: but you're conflating them with JS |
| 14:49 | <SimonSapin> | I’m talking about the arrangement of 16-bit code units when these subsystems interact with JS |
| 14:50 | <annevk> | But that's saying something about those subsystems, not JS |
| 14:50 | <SimonSapin> | sure |
| 14:50 | <annevk> | So in practice, JS strings are consist of 16-bit integers |
| 14:50 | <annevk> | Good |
| 14:50 | <SimonSapin> | I’d still like to have a name for that arrangement of code units |
| 14:50 | <annevk> | s/are/still/ |
| 14:51 | <SimonSapin> | yeah, I’m not disputing that |
| 14:51 | <annevk> | It's utf-16, unless the lone surrogates are rendered, which I think they are |
| 14:51 | <annevk> | In which case it would be WTF-16 indeed |
| 14:52 | <SimonSapin> | that’s what I mean |
| 14:52 | <annevk> | But that depends on the user agent |
| 14:52 | <annevk> | However, network is always utf-8 |
| 14:56 | <gsnedders> | SimonSapin: it's UTF-16, it's just sometimes not valid UTF-16 |
| 14:57 | <annevk> | gsnedders: if you don't replace the lone surrogates, it's not utf-16 |
| 14:57 | <SimonSapin> | gsnedders: but when it’s invalid we give it a different meaning |
| 15:08 | <gsnedders> | The example given in D89 of Unicode 6.3 makes it pretty clear that the intention is that it's a UTF-16 string |
| 15:09 | <gsnedders> | Oh, no, I'm misreading. It's the point it's still a Unicode string even if it's not a UTF-16 one. |
| 15:10 | <gsnedders> | it refers to them as "Unicode 16-bit strings" |
| 15:10 | <zcorpan> | mathiasbynens: r? https://critic.hoppipolla.co.uk/r/2725 |
| 15:12 | <zcorpan> | mathiasbynens: if you can find more differences between HTML's and JS's parsing of ints and floats, would be good to add |
| 15:18 | <annevk> | gsnedders: sounds worthy of WTF-16 to me |
| 15:18 | <annevk> | but that name kind of implies you could serialize it, which is probably what's wrong with such names |
| 15:36 | <TabAtkins> | annevk: You can serialize it, though. Or do you mean "it implies that tools would have a serialization for it"? |
| 16:04 | <annevk> | TabAtkins: to be more clear, it looks like a transport encoding with such a name |
| 16:05 | <annevk> | transfer is prolly more appropriate |
| 16:06 | <TabAtkins> | annevk: Yeah, makes sense. |
| 16:07 | <annevk> | zcorpan: do we really want to keep having that difference between JS and HTML? |
| 16:14 | <Ms2ger> | annevk, well, Aryeh argued against the difference, nobody wanted to change their implementation |
| 16:14 | <Ms2ger> | annevk, and I believe Hixie wasn't happy about JS depending on unicode for space characters |
| 16:15 | <Hixie> | depending on unicode for the meaning of a language is crazy |
| 16:15 | <Hixie> | it means that each time they add new characters, existing scripts might stop working or work differently |
| 16:16 | <caitp> | i'm sure the same argument has been made about depending on ascii codepoints meaning specific things too |
| 16:16 | <annevk> | Ms2ger: didn't the implementations use the ECMAScript semantics? |
| 16:16 | <Ms2ger> | annevk, no |
| 16:22 | <Hixie> | caitp: ascii doesn't change every year |
| 16:22 | <Hixie> | and also, nobody is suggesting depending on ascii |
| 16:23 | <caitp> | it changes whenever someone invents a new variant on it |
| 16:23 | <gsnedders> | tbf, Unicode categories change exceptionally rarely |
| 16:23 | <Hixie> | caitp: that... isn't how that works |
| 16:24 | <caitp> | i think it's just over your head |
| 16:24 | <TabAtkins> | caitp: You might also be thinking of all the ASCII-compatible encodings, which all share the same first 128 codepoints with ASCII. |
| 16:24 | <TabAtkins> | caitp: Why you trolling? |
| 16:24 | <caitp> | which is fine, but the concept isn't that complicated. region A decides that this combination of bits means a new thing, suddenly it isn't read consistently world wide |
| 16:24 | <caitp> | every time a new variant is invented |
| 16:25 | <caitp> | which isn't as often anymore, but used to happen a fair bit |
| 16:25 | <TabAtkins> | Again, those were all ascii-compatible. |
| 16:25 | <TabAtkins> | ASCII is a 7-bit encoding, and lots and lots of encodings agreed on those 7 bits. |
| 16:25 | <caitp> | no, they were partially compatible |
| 16:25 | <caitp> | even bits under 0x80 changed meaning |
| 16:25 | <caitp> | not in an especially harmful way, but it did change |
| 16:26 | <TabAtkins> | Further, "someone, somewhere, inventing a new way to interpret some bits" is not equivalent to "the definition of those bits has changed". |
| 16:26 | <caitp> | the point is that it's not really a new problem, it's existed forever and it doesn't matter what encoding you use, you still run into it |
| 16:27 | <Hixie> | man, i just got out of that troll hole and tab fell right in instead :-P |
| 16:27 | <TabAtkins> | caitp: No, you are seriously missing, like, all of the points. |
| 16:27 | <caitp> | no, you are missing the points =) |
| 16:27 | <caitp> | and that's okay |
| 16:27 | <TabAtkins> | lol ok |
| 16:28 | <caitp> | you assign meaning to a combination of bits, over time, the honouring of that particular meaning that is convenient to you changes, regionally or worldwide |
| 16:29 | <TabAtkins> | The widely accepted definition of ASCII has not changed in a long time. Even if some regions invent an encoding that is not fully ASCII-compatible, that does not change the definition of ASCII that everyone else depends on. |
| 16:29 | <Hixie> | and that wouldn't even matter if it had |
| 16:29 | <Hixie> | because we don't reference ASCII |
| 16:29 | <TabAtkins> | Even if there was a period wherein ASCII was updated or changed regularly (without looking things up, I dunno), that period is long past. |
| 16:30 | <TabAtkins> | Whereas Unicode is updated every few years right now, and they do extend categories, potentially including the whitespace category. |
| 16:30 | <caitp> | sure it's long past, until someone does it again |
| 16:30 | <TabAtkins> | Literally no one is going to update ASCII, and pretending that it's even a remote possibility that we should worry about (in comparison to the worry about Unicode changing) is ridiculous. |
| 16:31 | <caitp> | I wouldn't discount it |
| 16:31 | <caitp> | crazier things happen every day |
| 16:31 | <TabAtkins> | Good for you. Apparently you like paying excessive attention to things with vanishing probability. Don't pretend that anyone else cares about that possibility, though, and is "missing the point" for not caring about it. |
| 16:32 | <caitp> | but that's not really the point, the point is that it's an example of the fact that it really doesn't matter whether you depend on unicode or not, at some point, meanings will change |
| 16:32 | <jgraham> | This is not how the world works, people |
| 16:32 | <TabAtkins> | *Additionally*, as Hixie said, *HTML doesn't depend on ASCII for the definition of whitespace*. |
| 16:32 | <caitp> | the number of people in this room who know how the world works is precisely zero |
| 16:32 | <caitp> | self included |
| 16:33 | <jgraham> | If you have a critical mass of people depending on a certian behaviour in software, that behaviour will not change |
| 16:33 | <caitp> | you're bringing html into it, but it doesn't matter, html is kind of irrelevant to it |
| 16:33 | <jgraham> | That applies to both unicode and ascii |
| 16:34 | <jgraham> | Unicode has the additional problem that there are a large number of cases where there could be a specified behaviour that doesn't get a critical mass of dependent users |
| 16:34 | <caitp> | the fact is that it will change when it's convenient |
| 16:34 | <TabAtkins> | jgraham: Right, which is why claiming to depend on Unicode for a potentially important category definition, when Unicode's interests aren't really aligned with "make sure JS keeps working", is silly. In reality, JS impls depend on a static set, and won't follow Unicode if anything ever changes in a breaking fashion. |
| 16:34 | <jgraham> | caitp: I think you aren't making a point of any substance. |
| 16:34 | <caitp> | that's fine, but you can just watch it and see |
| 16:35 | <Ms2ger> | TabAtkins, and in that case, we end up with some weird situation like "whitespace in Unicode from 2017" |
| 16:35 | <caitp> | it's just the way things are, nothing is ever set in stone |
| 16:35 | <jgraham> | "when it's convenient" is exactly the crux of the argument, but you are sweeping it under the carpet |
| 16:35 | <jgraham> | It is almost never convenient to break something that large numbers of people actually depend on |
| 16:36 | <caitp> | it's not convenient for some people |
| 16:36 | <Domenic> | wait so ... we want to reference a dated unicode snapshot? O_O |
| 16:38 | <Ms2ger> | Domenic, no, we want to reference ASCII whitespace from encoding.s.w.o |
| 16:38 | <Ms2ger> | Domenic, except that parseInt doesn't want to do that |
| 16:46 | <Hixie> | what will eventually happen is the JS spec will just list a long series of numbers that are to be treated as whitespace |
| 16:48 | <Hixie> | oh my god i just noticed something |
| 16:48 | <Hixie> | the w3c main page no longer says that their mission is to lead the web to its full potential! |
| 16:49 | <Hixie> | it's still in the <title>s for the News and Blog pages |
| 16:49 | <Hixie> | i wonder if that's an oversight |
| 16:55 | <hober> | potentialgate? |
| 16:55 | <TabAtkins> | Hixie: What's the name of the actual file that constitutes the single-page spec? |
| 16:57 | <Hixie> | um, /, i guess? |
| 16:57 | <Hixie> | what do you mean? |
| 16:57 | <Hixie> | like, in svn? |
| 16:57 | <Hixie> | complete.html is the file in svn. Also index. Same file. For legacy reasons I check it in under both names. |
| 16:59 | <Hixie> | hober: well i mostly just think it's humourous. Something to point at as showing a culture shift if I ever write a blog post about the sad fall of the w3c. :-) |
| 17:00 | <TabAtkins> | Hixie: I think I need to ask plinss why Shepherd asks for the actual file, in addition to the normal url. |
| 17:00 | <TabAtkins> | Like, it wants to know about "Overview.html" for CSS specs. |
| 17:01 | <Hixie> | huh |
| 17:02 | <Hixie> | yeah it's just "" in that case |
| 17:04 | <annevk> | "(PS - Going forward, also we plan to support the ability to add HSTS headers.)" |
| 17:04 | <annevk> | maybe we should have just put Cloudflare in front of whatwg.org |
| 17:06 | <jgraham> | You still want SSL from cloudflare to your servers |
| 17:07 | <TabAtkins> | Which I think you can do with self-generated certs? |
| 17:07 | <jgraham> | Maybe, I'm not sure |
| 17:07 | <TabAtkins> | I mean, you just tell CloudFlare what your certs are, there's no risk of impersonation. |
| 17:08 | <Domenic> | yep |
| 17:08 | <annevk> | TabAtkins: yup, they do that |
| 17:08 | <Domenic> | i was going to suggest cloudflare but it was like $15/month at the time |
| 17:09 | <TabAtkins> | You know that we can just expense that, right? |
| 17:09 | <Domenic> | i think we want to keep google money out of the whatwg as a general rule? |
| 17:09 | <annevk> | note that Cloudflare doesn't support the *.spec.whatwg.org thing for unpaid customers |
| 17:09 | <annevk> | just *.whatwg.org |
| 17:09 | <Domenic> | ahh |
| 17:10 | <annevk> | also, I'm somewhat glad went through the trouble, would have learned far less if we did something like this |
| 17:10 | <annevk> | I went* |
| 17:11 | <annevk> | Oh, through DreamHost Cloudflare would've been USD 10 |
| 17:11 | <Domenic> | per month though i assume |
| 17:12 | <TabAtkins> | annevk: But going through resellers delays your free ssl until they work out some technical kinks |
| 17:12 | <annevk> | yes |
| 17:12 | <annevk> | (to you both, it seems) |
| 18:53 | <zcorpan> | annevk: maybe not |
| 19:07 | <zcorpan> | does anyone see a problem with this example? https://html-differences.whatwg.org/#mathml-svg |
| 19:10 | <caitp> | does any browser ship with support for mathml yet? :o |
| 19:10 | <caitp> | i can't remember if gecko does or not |
| 19:13 | <TabAtkins> | zcorpan: No, what problem do you think might exist? |
| 19:13 | <zcorpan> | TabAtkins: i got a private email asking for the svg to be moved out of the <p> so that it would be rendered on a separate line |
| 19:13 | <TabAtkins> | ...why? |
| 19:14 | <zcorpan> | "The text "A green circle" now gets rendered above the circle, which is what most people might expect, expecially since the text has a colon "A green circle:"" |
| 19:15 | <zcorpan> | i can see that it's a bit ugly because the <svg> is 300x150, but i'm unsure about it being on a separate line is what most people expect (or whether the colon has anything to do with it) |
| 19:16 | <TabAtkins> | Yeah, I don't get that at all. A colon doesn't ever mean "the following content is on the next line". |
| 19:16 | <TabAtkins> | It's just an inline circle. |
| 19:16 | <TabAtkins> | Plus, who cares, it's a markup example that isn't even rendered in the document. |
| 19:16 | <zcorpan> | yeah |
| 19:26 | <smaug____> | caitp: Gecko has supported mathml like forever |
| 19:27 | <caitp> | it doesn't render the mathML dom in any special way though, as far as I can tell |
| 19:28 | <caitp> | so you still end up using one of the fancy "apply CSS or draw it with SVG" libraries to it |
| 19:29 | <caitp> | and then you wonder what the point of it ever was |
| 19:29 | <smaug____> | " it doesn't render the mathML dom in any special way though" ? |
| 19:30 | <zcorpan> | caitp: are you testing presentational mathml or content mathml? |
| 19:30 | <caitp> | "dom" was the wrong word |
| 19:31 | <caitp> | I'm talking about presentation here |
| 19:31 | <caitp> | since I'm not aware of any other use for mathML |
| 19:32 | <smaug____> | and I don't understand what Gecko doesn't render |
| 19:33 | <caitp> | ah don't worry about it |
| 19:33 | <smaug____> | https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test |
| 19:35 | <caitp> | people come up with wacky things which don't seem to solve any real problem on their own |
| 19:36 | <caitp> | maybe someone wants to programme matlab with it, who knows |
| 19:36 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22731 ... i don't understand ap |
| 19:37 | <ap> | zcorpan: ? |
| 19:38 | <zcorpan> | ap: the spec change wasn't unmotivated |
| 19:39 | <ap> | zcorpan: well, it was definitely against what all browsers did at the time, and I assumed that no one would intentionally break compatibility like that |
| 19:40 | <zcorpan> | ap: it happens sometimes if it doesn't break the *web* and there's a reason to change |
| 19:41 | <ap> | zcorpan: I very clearly explained in the bug why this was a change for the worse, and it got WONTFIXed simply because it was only a little step to the worse |
| 19:43 | <ap> | like, maybe someone sometimes sould want a different behavior, so why not take an existing API and change it |
| 19:43 | <zcorpan> | ap: that's not my understanding. my understanding is that Hixie considers the change to be a little step to the *better*. and two browsers were interested enough to implemented on a relatively short time and abarth didn't see the security problem |
| 19:44 | <ap> | zcorpan: going against an explicit recommendation of base64 spec is super arbitrary |
| 19:44 | <Hixie> | personally i don't really care either way, but some people thought it was a step to the better, yeah |
| 19:45 | <Hixie> | i'm happy to change the spec if the momentum goes the other way |
| 19:45 | <Hixie> | my understanding is that the decision wasn't arbitrary, though |
| 19:45 | <zcorpan> | agree |
| 19:45 | <Hixie> | it was intentional because a bunch of people would first strip whitespace then call this |
| 19:45 | <Hixie> | and it seemed simpler to not have them do this, or something |
| 19:46 | <Hixie> | also i don't really understand the security risk in this specific case (i agree that in some cases there's a problem) |
| 19:46 | <ap> | Hixie: as I said in the bug, "The bar was quite high, and I do not think that this change came anywhere close to meeting it." |
| 19:46 | <Hixie> | the bar i use is almost always "two browsers implement the change" |
| 19:46 | <Hixie> | that bar was met |
| 19:46 | <Hixie> | no? |
| 19:46 | <ap> | Hixie: also, not sure why it is difficult for anyone to see the security concern |
| 19:47 | <ap> | Hixie: obviously, this introduces a covert channel where it used to be none |
| 19:47 | <ap> | Hixie: yes, it is not an attack against the _browser_ |
| 19:47 | <ap> | Hixie: which may be why abarth doesn't see it |
| 19:47 | <ap> | Hixie: but there are many actors, each of whom have their security to worry about |
| 19:48 | <Hixie> | can you give a sample scenario where there's a concrete security problem? |
| 19:48 | <ap> | Hixie: just take a look at webcrypto security discussions... these are way different from what one is accustomed to seeing elsewhere |
| 19:48 | <ap> | Hixie: let me think about a specific example... |
| 19:52 | <ap> | Hixie: I don't have anything specific like "this breaks this particular software", but the change would break parenting and corporate filters that used to assume that base64 in a browser follows RFC 4648 recommendations (and whose authors tested browsers to see that they did). They would simply fail to decode the content, which would be then displayed |
| 19:52 | <ap> | Hixie: it's hard to come up with anything specific for covert channel. These are always special snowflakes |
| 19:53 | <ap> | Hixie: like, watermarking where you don't expect any. or piggy-backing on an existing channel to exfiltrate data (like sending out stolen data over DNS) |
| 19:55 | <Hixie> | i understand the attack in principle, i just don't understand how this specific API would be subject to it |
| 19:55 | <Hixie> | like i said, my understanding is that Aryeh when making this call found that most people strip spaces first anyway |
| 19:57 | <ap> | Hixie: yes, clearly, people who strip the spaces would not be affected |
| 19:57 | <Hixie> | anyway, i'm not the one to convince, really |
| 19:58 | <Hixie> | i'm just following the usual principle. two implementations changed. i'm just following the momentum. |
| 19:59 | <ap> | Hixie: the real outcome is that there is increased potential for websites to work in Chrome and Firefox, but not in Safari - as release cycles are different. Certainly that's a financially desirable outcome for a certain percentage of standards community |
| 20:00 | <ap> | trivial performance improvements pale in comparison to the diversity introduced into the platform |
| 20:00 | <caitp> | in the real world, authors are a lot more likely to make sure their website works on an ipad than they are to make sure it works on b2g |
| 20:01 | <caitp> | regardless of what direction standards are moving |
| 20:01 | <ap> | caitp: unfortunately, it too often happens that this is achieved with wrong techniques - e.g. by special casing a specific user-agent, and having a separate implementation for that |
| 20:01 | <caitp> | maybe, but that's just the nature of the game |
| 20:01 | <ap> | caitp: then everything breaks again with a new browser release |
| 20:01 | <caitp> | they follow the money |
| 20:03 | <ap> | caitp: that is certainly reasonable. What I request - here and also in general - is that the standards community is less cavalier with changing well established and fully interoperable APIs |
| 20:04 | <Hixie> | ap: i don't disagree with what you're saying, but changing the spec won't magically make firefox and chrome change back, if they think the change is a good idea. Just like changing the spec didn't magically change Safari since you think it's a bad idea. :-) |
| 20:05 | <ap> | Hixie: it does seem too late now. It probably wasn't too late when the spec bug was filed |
| 20:06 | <Hixie> | ap: i don't think anything really changed between then and now, but ok |
| 20:07 | <Hixie> | ap: i'm not sure what i should have done differently here. |
| 20:07 | <ap> | Hixie: I think that no one has yet shipped at that point |
| 20:07 | <Hixie> | ap: i feel you're saying i dropped the ball, but what would have been a better way to deal with it? |
| 20:10 | <ap> | Hixie: I think that the spec change should not have been made without a measured performance improvement on some pre-existing use case or test. I don't have a recommendation about how the change could be dealt with when questioned - as you know, I'm not very active in the standards community, and don't know any of the poilitics or even the procedures |
| 20:11 | <ap> | Hixie: ideally, a change that should not have been made would be undone somehow |
| 20:12 | <Hixie> | ah, well, the spec change wasn't in HTML |
| 20:12 | <Hixie> | that predates my involvement |
| 20:13 | <Hixie> | define "should not have been made", though? Here I had two browser vendors on board and agreeing it was a good idea, as well as the spec author for that feature. |
| 20:13 | <Hixie> | and only one vendor against it |
| 20:14 | <Hixie> | objectively, i don't really see why i would have concluded that it was a mistake |
| 20:14 | <Hixie> | (not sure why it would be a performance thing. It was just a convenience change, as I understand it, not one for perf.) |
| 20:16 | <Hixie> | ap: i'm not trying to gloss over this. I'm just genuinely not sure what I should have done differently here. It seems like every step was objectively reasonable. |
| 20:17 | <ap> | Hixie: Well, we have two vendors with very quick release cycles, who naturally favor "embrace, extend and extinguish" approach |
| 20:17 | <ap> | Hixie: the "two vendor" rule indeed encourages that |
| 20:18 | <ap> | Hixie: and there is no reason why vendors should not use the standards process to their competitive advantage, and to the disadvantage of others |
| 20:18 | <annevk> | zcorpan: context? |
| 20:19 | <zcorpan> | annevk: "do we really want to keep having that difference between JS and HTML?" |
| 20:19 | <ap> | Hixie: obviously, there are many changes that disadvantage old browsers - adding anything does! |
| 20:19 | <Hixie> | ap: well, certainly i would encourage you to follow the other three browsers and move to a more frequent deployment model |
| 20:20 | <zcorpan> | ap: we can compensate by removing things :-) |
| 20:20 | <ap> | Hixie: but authors would be more likely to conditionalize WebGL something and fall back, than a call to atob. This tiny convenience just creates quite a bit annoyance |
| 20:20 | <ap> | zcorpan: indeed :-))) |
| 20:22 | <Hixie> | ap: but i don't really see how i could change my approach to make it more balanced... i mean, giving IE and Safari a higher weight in considerations seems like something that would be considered even less fair |
| 20:24 | <ap> | Hixie: My assumption is that there was no problem to begin with, and the idea to add some convenience was arbitrary. That |
| 20:24 | <ap> | s's something one wouldn't do even in a private platform |
| 20:25 | <ap> | Hixie: like, we don't change Cocoa API behaviors any time there is an opportunity to improve |
| 20:25 | <boogyman> | Hixie: isn't the "2 vendor" rule weighting more towards the vendors that have "very quick release cycles" ? |
| 20:25 | <Hixie> | ap: as i said, i wasn't involved in that decision |
| 20:26 | <Hixie> | ap: that was done in the editing spec, i only got involved later when the APIs were moved to the HTML spec already in that state |
| 20:26 | <Hixie> | boogyman: that is ap's argument, though i don't really understand how to quantify that |
| 20:26 | <ap> | Hixie: I understand this |
| 20:26 | <Ms2ger> | boogyman, depends on whether you require shipping |
| 20:27 | <zcorpan> | mathiasbynens: http://www.chromestatus.com/metrics/feature/timeline/popularity/44 |
| 20:27 | <zcorpan> | mathiasbynens: maybe pattern="" can have u always on? |
| 20:27 | <boogyman> | As an author, I like earlier adoption of new features/functionality, but I do think there should be a happy medium for vendors to weigh in. |
| 20:28 | <Hixie> | ap: (i'm not sure I agree that we should never make APIs more convenient, but I agree that in this case it's not obvious that the win was worth it.) |
| 20:30 | <zcorpan> | mathiasbynens: https://www.w3.org/Bugs/Public/show_bug.cgi?id=11011 earlier discussion about i |
| 20:32 | <ap> | Hixie: I think that one test would be - would I make a similar change in a private API? If "no", or "maybe", then it's worth stopping and demonstrating tangible benefit bigger than convenience before making it on the Web. I think that allowing spaces in an existing atob function would be frowned upon in a native API, even though that's a backwards compatible change |
| 20:32 | <JonathanNeal> | Ms2ger hsivonen Would you know why empty iframes invisible in Firefox? Firefox is the only major browser in any OS to not show the red box: http://jsfiddle.net/nft8puq5/ |
| 20:33 | <annevk> | ap: I'm not sure that's going to help many people |
| 20:33 | <annevk> | ap: there's not an agreed upon policy for private APIs either |
| 20:33 | <JonathanNeal> | Is there a security concern with empty iframes? Is there a spec that isn't clear on what should happen? |
| 20:34 | <Ms2ger> | JonathanNeal, it flashes up |
| 20:36 | <Ms2ger> | JonathanNeal, not sure what's up. Create a standalone case and file a bug, please |
| 20:36 | <annevk> | Hixie: a lot of specifications now have checks on global environments |
| 20:36 | <annevk> | Hixie: whether something is a document or worker or shared worker environment, etc. |
| 20:37 | <zcorpan> | Ms2ger: hsivonen: about:blank ghost? |
| 20:37 | <annevk> | Hixie: since you don't want global environments to leak to APIs to much, consider abstracting that too somehow |
| 20:37 | <Ms2ger> | zcorpan, I don't see why there'd be two |
| 20:38 | <annevk> | Hixie: on another note, is it worth pointing out on es-discuss that what you and Allen agreed to is a hack and is going to break as soon as ES wants something more complicated from their loop? |
| 20:39 | <annevk> | ap: on another note, it would help if WebKit were responsive to queries for input on new or existing standards; it seems copying people on bugs is not sufficient to get their attention; better ideas? |
| 20:43 | <annevk> | Hixie: I'll comment on the bug about the global environment thing |
| 20:50 | <JonathanNeal> | Ms2ger: have a recommendation on how i can make my case even more standalone than the js fiddle, or is that simple enough? |
| 20:50 | <Ms2ger> | JonathanNeal, one html file? |
| 20:51 | <mathiasbynens> | zcorpan: I was hoping for always-`u` `pattern` but assumed it would break the Web |
| 20:51 | <mathiasbynens> | e.g. `\W` is different |
| 20:52 | <zcorpan> | mathiasbynens: might be worth analyzing |
| 20:52 | <Hixie> | annevk: environment settings objects contain a link to the global, but yeah, we can separately also include a "kind" or something if that would help |
| 20:53 | <Hixie> | annevk: please feel free to comment on es-discuss |
| 20:53 | <Hixie> | annevk: i'm not sure when allen is making the changes i mentioned, if at all |
| 20:54 | <ap> | annevk: can't talk for others; personally, I think that I do respond when CC'ed or asked, as long as I have anything to say |
| 20:55 | <annevk> | Hixie: kind sounds alright; just looking out for you here since you cared about making things not depend on ES ;-) |
| 20:55 | <Hixie> | well the global is an interface, that's not depending on JS |
| 20:55 | <Hixie> | per se |
| 20:56 | <Hixie> | :-) |
| 20:56 | <annevk> | ap: I often end up copying Maciej and Ted for high-level feedback, don't really want to bother you |
| 20:56 | <ap> | annevk: makes sense, I would rarely want to provide high level feedback |
| 20:56 | <Hixie> | as in, if you go settings object -> specified global -> instanceof, as opposed to global object -> instanceof |
| 20:57 | <annevk> | Hixie: ah yes, the global could work |
| 20:57 | <Hixie> | but we can have an explicit "kind" too |
| 20:57 | <Hixie> | just to make it more explicit |
| 20:57 | <annevk> | Hixie: note that JavaScript instanceof is not safe across realms |
| 20:58 | <annevk> | Hixie: sgtm |
| 20:58 | <Hixie> | i didn't mean a real instanceof, but yeah :-) |
| 21:09 | <zcorpan> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26195 also affects <img sizes> fwiw |
| 21:10 | <Hixie> | do you agree with the decision? |
| 21:11 | <zcorpan> | i don't care strongly either way. TabAtkins thinks comments should be allowed iirc |
| 21:11 | <Hixie> | k |
| 21:11 | <annevk> | Hixie: shouldn't email use https://url.spec.whatwg.org/#concept-domain-to-ascii too? |
| 21:11 | <annevk> | Hixie: rather than punycode directly |
| 21:11 | <Hixie> | it doesn't really matter |
| 21:11 | <Hixie> | it's a UI thing |
| 21:14 | <annevk> | yeah, I've got news for you, UI matters |
| 21:15 | <TabAtkins> | Hixie: zcorpan: Yeah, comments should be allowed, because otherwise it's a switch in the parser for no gain. |
| 21:16 | <TabAtkins> | Plus remote possibility of code not moving cleanly between contexts that use the same value set. |
| 21:17 | <Hixie> | i believe mike's proposals was just an authoring conformance requirement, no change to the parser |
| 21:17 | <Hixie> | annevk: UI matters but there's no interop issue, is my point |
| 21:17 | <TabAtkins> | Probably insignificant, but still, comments don't cause any actual problem for browsers. |
| 21:17 | <Ms2ger> | I thought we all worked through that? |
| 21:17 | <Hixie> | annevk: it's a quality of implementation thing |
| 21:19 | <TabAtkins> | Hixie: Yeah, but I've used comments in weird spots before. Dropping a bit for why a length is s particular weird value, etc. I can see potential (small) value in allowing them. |
| 21:20 | <Hixie> | TabAtkins: yeah no disagreement from me, i wontfixed the bug :-) |
| 21:20 | <Hixie> | TabAtkins: i was just making sure mike's argument was accurately represented |
| 21:23 | <Hixie> | annevk: you could file a bug on ES for the event loop approach to be inverted |
| 21:41 | <zcorpan> | mmmm broccoli |
| 21:41 | zcorpan | grows his own broccoli |
| 21:41 | zcorpan | also reads w3cmemes |
| 23:13 | <JonathanNeal> | Might anyone here be able to guide me through filing an issue with Firefox? |
| 23:15 | <caitp> | you basically go through the annoying process of signing up for bugzilla (which if you've done for any of the w3/whatwg/webkit/llvm/whatever projects, you're familiar with), then you basically just file |
| 23:15 | <caitp> | and smaug or someone will shortly tell you you're wrong and your bug is wrong (kidding kidding) |
| 23:21 | smaug____ | kicks caitp :) |
| 23:22 | <smaug____> | JonathanNeal: assuming it is an API related bug, better to not fire Firefox bug, but a Core Gecko bug, https://bugzilla.mozilla.org/enter_bug.cgi?product=Core |
| 23:22 | <JonathanNeal> | I’m having a lot of trouble figuring out which category in Firefox this belongs. |
| 23:22 | <JonathanNeal> | It has to do with how elements are rendered on a page. |
| 23:23 | <smaug____> | layout or graphics then, probably |
| 23:23 | <JonathanNeal> | Don’t see that @ https://bugzilla.mozilla.org/describecomponents.cgi?product=Firefox |
| 23:23 | <smaug____> | what did I just say ;) |
| 23:23 | <smaug____> | file a core gecko bug |
| 23:24 | <smaug____> | it is more effective if the issue is about API or layout or such |
| 23:24 | <smaug____> | https://bugzilla.mozilla.org/enter_bug.cgi?product=Core |
| 23:25 | <caitp> | if you get it wrong, chances are good if someone notices, it will get moved to the right place |
| 23:25 | <smaug____> | yup |
| 23:27 | <JonathanNeal> | thanks |
| 23:33 | <JonathanNeal> | smote me, smaug____ https://bugzilla.mozilla.org/show_bug.cgi?id=1074549 |
| 23:35 | <smaug____> | hmm, sounds like about:blank loading issue |
| 23:35 | <smaug____> | JonathanNeal: what happens if you append the iframe, add load event listener, and in that listener set the color? |
| 23:36 | smaug____ | doesn't know if any browser does about:blank loading right, or what even is the right about:blank behavior |
| 23:36 | <smaug____> | hsivonen would know |
| 23:38 | <JonathanNeal> | smaug____: it doesn’t make a difference, it visually hides the content of the iframe. |
| 23:38 | <JonathanNeal> | You can inspect the content, and it’s all there, and you can add event listeners and they will fire. |
| 23:40 | <smaug____> | JonathanNeal: no, the content doesn't have "hello world" |
| 23:40 | <smaug____> | are you looking at the first document content? |
| 23:40 | <smaug____> | access the content document after load event has fired for the iframe |
| 23:41 | <JonathanNeal> | Check out iframe.contentWindow.document.body.childNodes[0] |
| 23:41 | <JonathanNeal> | It’s a text node. |
| 23:44 | <JonathanNeal> | smaug____: it doesn’t make a difference for me whether i add or access the content before or after its windows’ content event has fired. |
| 23:44 | <JonathanNeal> | content event, er, load event |
| 23:44 | <smaug____> | I don't see the text node in iframe.contentDocument.body |
| 23:48 | <JonathanNeal> | smaug____: we can force the inspector into seeing it, watch, it’s fun. |
| 23:49 | <smaug____> | ? |
| 23:49 | <JonathanNeal> | Try this: |
| 23:49 | <JonathanNeal> | iframe.contentWindow.document.body.appendChild(document.createElement('p')).appendChild(document.createTextNode('Hello, World!')); |
| 23:49 | <JonathanNeal> | The inspector won’t see it. |
| 23:49 | <smaug____> | yes, after that it is there |
| 23:49 | <JonathanNeal> | Then try: console.log(iframe.contentWindow.document.body.firstChild); |
| 23:49 | <smaug____> | I'm talking about your testcase |
| 23:49 | <JonathanNeal> | then click it, and the inspector will see it. |
| 23:50 | <JonathanNeal> | Even in the testcase, if you look at iframe.contentWindow.document.body.firstChild it’s a textnode. |
| 23:50 | <JonathanNeal> | You should see something like #text “Hello World" |
| 23:51 | <JonathanNeal> | well, plus the comma and exclamation point. |
| 23:52 | <smaug____> | don't see |
| 23:53 | <smaug____> | JonathanNeal: http://pastebin.mozilla.org/6664082 gives the text + red color |