| 00:23 | <GPHemsley> | Hixie: Hmm... not easily. I don't think we can do it from within the normal interface, but we can probably do it by hacking the template/theme somehow. |
| 00:26 | <GPHemsley> | Hixie: Hmm, actually, we might be able to do it with some custom CSS. |
| 00:26 | <GPHemsley> | annevk: Were there other pages that you didn't want to see the anonnotice on? |
| 00:33 | <annevk> | GPHemsley: on the wiki? All of them I think |
| 00:33 | <annevk> | GPHemsley: you solved a minor problem with something far too heavyweight in my opinion |
| 00:34 | <GPHemsley> | annevk: Did you have an alternative solution? |
| 00:34 | <annevk> | GPHemsley: not sure how many page views the thing gets from non logged in users though, but whenever I visit it on my phone I dislike it |
| 00:35 | <annevk> | GPHemsley: maybe include the account banner on the registry pages |
| 00:35 | <annevk> | GPHemsley: the bit about specification discussions does not seem warranted |
| 00:35 | <annevk> | GPHemsley: we can just remind individuals of that fact every now and then |
| 00:35 | <annevk> | GPHemsley: or put in the FAQ |
| 00:39 | <GPHemsley> | Hixie: Gone from the FAQ page now. If there are any other pages where you want it gone, edit MediaWiki:Common.css (and remember to clear the cache by clicking on the clock in the upper right corner of the page in question). |
| 00:40 | <GPHemsley> | annevk: Everything in the anonnotice was done in response to something. |
| 00:40 | <annevk> | GPHemsley: I believe you, but I'm saying that boilerplate is not the right solution |
| 00:41 | <annevk> | GPHemsley: and that the problem might not be as big as you make it out to be |
| 00:41 | <annevk> | GPHemsley: the wiki is more read than written |
| 00:42 | GPHemsley | shrugs |
| 00:42 | <GPHemsley> | I'll revisit it at some point. |
| 01:54 | <rniwa> | sicking: yt? |
| 01:55 | <sicking> | rniwa: yup |
| 01:55 | <rniwa> | sicking: I just replied on your response to custom elements reaching CR |
| 01:55 | <rniwa> | sicking: as I mentioned in the email, we share the same concern you expressed |
| 01:56 | <rniwa> | sicking: in particular, it seems strange to move the custom elements spec into CR without moving other parts of the web components at least into the last call |
| 01:56 | <sicking> | agreed |
| 01:57 | <rniwa> | sicking: it might make sense to restrict the shadow DOM to only custom elements for now |
| 01:57 | <rniwa> | sicking: so that we don't have to resolve all the issues associated with attaching shadow DOM onto existing builtin html elements |
| 01:57 | <rniwa> | such as form controls, img, etc... that has been tricky to spec |
| 01:57 | <sicking> | don't know, i haven't followed this in enough detail |
| 01:57 | <rniwa> | hayato_: ping |
| 01:58 | <rniwa> | sicking: i think the problem, as you correctly pointed out, is that other vendors haven't had enough time to review the specifications :( |
| 01:58 | <rniwa> | sicking: i sympathize with google in that they've been working on this stuff for years |
| 01:58 | <rniwa> | but it'll be really unfortunate if we end up not being able to implement what's been spec'ed at the end of the day |
| 01:58 | <hayato_> | rniwa: y |
| 01:59 | <sicking> | yup |
| 01:59 | <rniwa> | hayato_: am I correct in saying that the reason shadow DOM spec. is having a hard to move forward |
| 01:59 | <rniwa> | hayato_: is because we can't really spec what happens with replaced elements, etc...? |
| 02:00 | <sicking> | rniwa: Is Dave Hyatt involved in the shadow DOM stuff at all from your side? It would be great to have his input |
| 02:00 | <rniwa> | hayato_: as far as I know, the behavior of shadow DOM is very well defined if we restrict ourselves to custom elements. am I wrong on this? |
| 02:00 | <rniwa> | sicking: unfortunately not that much at this point :( |
| 02:00 | <rniwa> | sicking: but I'm working with Sam and Maciej |
| 02:00 | <hayato_> | rniwa: let me catch up. what topic are you discussing? shadow dom on built-in elements? |
| 02:00 | <rniwa> | sicking: and they're also familiar with XBL so hopefully I've got it covered |
| 02:01 | <rniwa> | hayato_: yeah |
| 02:01 | <rniwa> | hayato_: so there is a concern sicking raised |
| 02:01 | <rniwa> | hayato_: which is that other browser vendors haven't had a time to review custom elements |
| 02:01 | <rniwa> | hayato_: and we have a concern that moving custom elements spec. forward without moving the rest of web components forward might be risky |
| 02:01 | <rniwa> | hayato_: in that we might end up having to "fix" custom elements later |
| 02:02 | <hayato_> | rniwa: there is a lot of unclear issues on shadow dom for built-in elements. |
| 02:02 | <rniwa> | hayato_: yeah |
| 02:02 | <rniwa> | hayato_: so why can't we punt that for now and move with the rest of the spec? |
| 02:02 | <hayato_> | rniwa: and there is no strong demand for that. |
| 02:02 | <rniwa> | hayato_: as far as I understand it, there is a tremendous value in supporting shadow DOM for custom elements |
| 02:02 | <rniwa> | hayato_: right |
| 02:03 | <rniwa> | hayato_: and extending the spec to support attaching shadow DOM on bulletin elements is a natural extension we can add later |
| 02:03 | <rniwa> | hayato_: so we can spec. the shadow DOM for custom elements so that we wouldn't block custom elements forever |
| 02:03 | <rniwa> | hayato_: does that make sense? |
| 02:03 | <rniwa> | sicking: ^ |
| 02:04 | <sicking> | like I said, i haven't looked at the shadow DOM spec enough to have an opinion on this |
| 02:04 | <rniwa> | sicking: okay. |
| 02:04 | <rniwa> | sicking: will you be fine with spec'ing shadow DOM just for custom elements as v1 though? |
| 02:04 | <hayato_> | spec is here: http://w3c.github.io/webcomponents/spec/shadow/#html-elements-and-their-shadow-trees |
| 02:04 | <sicking> | i'll defer to William Chen and mrbkap |
| 02:04 | <rniwa> | sicking: or do you think attaching shadow DOM on builtin shtml elements is an important use case? |
| 02:04 | <rniwa> | mrbkap: ping? |
| 02:04 | <hayato_> | rniwa: But this is outdated. |
| 02:05 | <sicking> | i definitely think that attaching shadow DOM to form controls is an important use case. It might be part of one solution for styling form controls |
| 02:05 | <sicking> | which is a sorely needed feature |
| 02:05 | <hayato_> | tkent-san has been working on supporting shadow dom for built-in element, such as input elements in blink. |
| 02:06 | <rniwa> | sicking: isn't that decorator though |
| 02:08 | <hayato_> | we thought that attaching Shadow DOM to built-in elements is important use case, but it turned out there is no much demands from developers. |
| 02:08 | <esprehn> | We can't restrict it to custom elements without making shadow dom and custom elements tightly coupled |
| 02:08 | <rniwa> | esprehn, hayato_: we can add some optional argument in document.register to create a shadow DOM, right? |
| 02:09 | <esprehn> | For example a browser may implement support for one before the other, shipping shadow dom shouldn't be blocked on custom elements |
| 02:09 | <rniwa> | esprehn: but nobody can ship shadow DOM because there is no spec. |
| 02:09 | <esprehn> | It had a spec, what do you mean? |
| 02:09 | <rniwa> | esprehn: attaching shadow DOM on builtin elements is undefined as is |
| 02:10 | <esprehn> | It is not undefined |
| 02:10 | <esprehn> | No more than attaching it to a div or a span, you mean specific things like input |
| 02:10 | <hayato_> | rniwa: http://w3c.github.io/webcomponents/spec/shadow/#html-elements-and-their-shadow-trees is trying to address that. |
| 02:10 | <rniwa> | esprehn: input element is a builtin element |
| 02:11 | <esprehn> | So is div, but shadow dom works fine with it |
| 02:11 | <rniwa> | esprehn: for the spec to have a defined behavior for builtin elements, it needs to define behaviors of attaching shadow DOM on every single element we have |
| 02:11 | <rniwa> | esprehn: including SVG and MathML elements |
| 02:11 | <esprehn> | Or it could allow it only only div, span, td, etc for now and we could expand it later |
| 02:11 | <rniwa> | esprehn: that'll be fine |
| 02:12 | <rniwa> | esprehn: I think the problem here is that we can't move the spec. forward because there are too many edge cases to consider |
| 02:12 | <esprehn> | Restricting to only custom elements is too restrictive |
| 02:12 | <rniwa> | esprehn: maybe. |
| 02:12 | <rniwa> | esprehn: but what are use cases of using shadow DOM for other elements than custom elements? |
| 02:13 | <esprehn> | Wanting something special on a <td> |
| 02:13 | <rniwa> | esprehn: why don't you just put an element inside td then? |
| 02:13 | <esprehn> | I guess if you could <td is=foo> as custom |
| 02:14 | <esprehn> | That argument does not generalize |
| 02:14 | <esprehn> | We could eliminate all features :) |
| 02:14 | <rniwa> | esprehn: as I understand it, we've punted declarative syntax for custom elements for v2 |
| 02:14 | <esprehn> | Yes |
| 02:14 | <rniwa> | esprehn: then I don't see why we want to address that use case in shadow DOM v1 |
| 02:14 | <esprehn> | Huh? |
| 02:14 | <rniwa> | esprehn: <td is=foo> |
| 02:15 | <sicking> | rniwa: decorators would just be a way of attaching a shadow DOM. The actual rendering should still be done using shadow DOM |
| 02:15 | <rniwa> | sicking: sure |
| 02:15 | <esprehn> | Declarative custom elements and type extensions are totally unrelated |
| 02:15 | <rniwa> | sicking: but as I understand it, we haven't spec'ed that anywhere, right? |
| 02:15 | <rniwa> | sicking: so it seems natural for attaching shadow DOM to builtin elements and decorator to be spec'ed at the same time |
| 02:16 | <sicking> | rniwa: and in the meantime, being able to attach a shadow DOM to a form control, or a header/table/whatever is a great way of working around the lack of decorators |
| 02:16 | <esprehn> | Not having declarative syntax has no bearing on td is=foo |
| 02:16 | <sicking> | rniwa: maybe |
| 02:16 | <sicking> | rniwa: (the "maybe" being a reply to your latest comment) |
| 02:17 | <rniwa> | sicking: that's a good point. |
| 02:17 | <rniwa> | sicking: I'm not convinced that shadow DOM is the right way to address the problem of styling form controls though |
| 02:17 | <esprehn> | If we're concerned with complex widgets I'm fine with a whitelist |
| 02:17 | <rniwa> | sicking: it seems like we want something like what webkit exposes for form controls spec'ed |
| 02:18 | <sicking> | rniwa: what's that? |
| 02:18 | <esprehn> | Although the current idea (and what we implement) is that adding a ShadowRoot makes the native behavior go away |
| 02:18 | <sicking> | rniwa: see also my latest email to WHATWG |
| 02:18 | <rniwa> | sicking: these: http://trac.webkit.org/wiki/Styling%20Form%20Controls |
| 02:18 | <esprehn> | It turns into a <div> effectively |
| 02:21 | <sicking> | rniwa: yeah, something in that general direction. |
| 02:21 | <rniwa> | sicking: I think spec'ing these will be better than having authors replace builtin form controls |
| 02:22 | <rniwa> | sicking: and then can provide some form serialization mechanism |
| 02:22 | <esprehn> | Authors already replace the builtins |
| 02:22 | <esprehn> | The pseudo elements are not flexible enough |
| 02:23 | <sicking> | rniwa: authors need to be able to fully replace the styling though. So that you can turn a checkbox into a switch, or a <select> into a map |
| 02:23 | <rniwa> | sicking: why don't authors just write a custom element at that point? |
| 02:24 | <sicking> | rniwa: accessibility |
| 02:24 | <sicking> | rniwa: and you could get better platform integration |
| 02:24 | <rniwa> | sicking: but if authors are replacing it with a shadow DOM or whatever, then accessibility is somewhat broken unless they've explicitly set tabindex, etc... right? |
| 02:24 | <sicking> | rniwa: which is kind'a the same thing |
| 02:24 | <esprehn> | Or because they want the HTMLSelectElement API or search engines |
| 02:25 | <sicking> | rniwa: and having to re-implement the full form API, and keep it up-to-date as the web grows, seems annoying |
| 02:25 | <sicking> | rniwa: no. accessibility should still work with a different rendering |
| 02:25 | <rniwa> | esprehn: API on HTMLSelectElement wouldn't work because map isn't a select element. |
| 02:26 | <esprehn> | Yes it is |
| 02:26 | <sicking> | rniwa: i.e. a screenreader would still be able to tell the user that a checkbox is a checkbox and that it can be flipped, and let the user use voice commands to flip it, even if it's rendered as a switch |
| 02:26 | <rniwa> | sicking: how so? AT wouldn't know how to interact with the new UI. |
| 02:26 | <esprehn> | <select is=x-map> is indeed a select |
| 02:26 | <rniwa> | sicking: that is true although you can just use ARIA role for that. |
| 02:26 | <sicking> | rniwa: AT interacts with the DOM |
| 02:26 | <rniwa> | sicking: not really in webkit. |
| 02:27 | <sicking> | rniwa: AT should interact with the HTMLSelectElement even if there's a shadow DOM attached. |
| 02:27 | <esprehn> | Shadow dom just changes the presentation |
| 02:28 | <sicking> | yup |
| 02:28 | <sicking> | anyhow, time to head home |
| 02:28 | <rniwa> | sicking: night! |
| 02:28 | <sicking> | g'night! |
| 02:29 | <esprehn> | You create a renderblock instead of a renderselect, the select element API should continue working much like if the select was display none it continues working |
| 02:29 | <sicking> | rniwa: i think we agree on the central issue though. It seems too early to put these parts into CR |
| 02:29 | <rniwa> | sicking: yeah. |
| 02:30 | <rniwa> | esprehn: only if the implementation of map respected the changes made by that API and emulated the behavior |
| 02:30 | <rniwa> | esprehn: even then there are certain APIs that doesn't make any sense on maps |
| 02:31 | <rniwa> | e.g. what would changing "size" attribute mean on a map? |
| 02:31 | <rniwa> | or "multiple" |
| 02:31 | <rniwa> | would map respect "disabled" attribute? |
| 02:31 | <rniwa> | what if we added new attributes in the future like "disabled"? |
| 05:21 | <esprehn> | rniwa: what does changing size mean on a multi select on the iphone? |
| 05:22 | <esprehn> | rniwa: IIRC iOS shows only one option and shows a spinner in some native UI. The size attribute does nothing. |
| 07:21 | <marcosc> | Hixie: any chance you could comment on this thread? http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0725.html |
| 07:22 | <marcosc> | if we have to use JSON for application metadata... should it be in a <script> or <meta>/<link>? |
| 07:23 | <marcosc> | putting JSON into an attribute just feels really wrong to me |
| 07:24 | <marcosc> | if anyone else has an opinion, would really like to hear it |
| 07:25 | <marcosc> | Ms2ger: you're always full of kind things to say... http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0725.html |
| 07:25 | <Ms2ger> | Meh, manifests |
| 07:27 | <marcosc> | Ms2ger: you know you love it |
| 07:28 | <marcosc> | hsivonen: if possible, would really appreciate any feedback on http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0725.html |
| 07:43 | <hsivonen> | Ms2ger: we have whines about late metas. we might not have whines about double metas |
| 07:43 | <hsivonen> | marcosc: I'll take a look |
| 07:44 | <hsivonen> | for those who are participants in the HTML WG but don't actually read the mail: there's now a poll where, contrary to the usual mode of operation, the Chairs are counting votes: https://www.w3.org/2002/09/wbs/40318/polyglot-status-preference-poll/ |
| 07:45 | <marcosc> | hsivonen: thanks! really appreciate any feedback |
| 07:47 | <Ms2ger> | Oh wait |
| 07:47 | <Ms2ger> | It looks like this might actually be sent as a/xhtml+mxl |
| 07:47 | <Ms2ger> | xml, even |
| 07:58 | <hsivonen> | marcosc: is there an explanation somewhere why the new manifest doesn't need to come as early in the page load as the old (Hixie-AppCache) manifest? |
| 07:59 | <hsivonen> | marcosc: my immediate feedback is: why aren't inline manifests, <link> and <meta> all too late? |
| 07:59 | <marcosc> | hsivonen: because you only need that stuff async... if you ever need it at all |
| 07:59 | <marcosc> | most people don't go to a website and bookmark it straight away |
| 08:00 | <hsivonen> | marcosc: so no part of the first page load ever goes through the NavigationController? |
| 08:00 | <marcosc> | hsivonen: no. there is no relationship between manifest and navcon |
| 08:01 | <marcosc> | not yet, anyway |
| 08:01 | <hsivonen> | I guess I need to read more about what this thing is before I comment further |
| 08:01 | <marcosc> | http://manifest.sysapps.org/ |
| 08:02 | <hsivonen> | same as http://w3c.github.io/manifest/ apparently |
| 08:02 | <marcosc> | yep, same thing |
| 08:02 | <marcosc> | hsivonen: the long version is here http://w3c-webmob.github.io/installable-webapps/ |
| 08:03 | <marcosc> | (not done yet... but tell the whole story) |
| 08:03 | <marcosc> | hsivonen: section 3 is basically what we are trying to enable: http://w3c-webmob.github.io/installable-webapps/#add-to-homescreen |
| 08:25 | <Ms2ger> | Lovely: https://code.google.com/p/chromium/issues/detail?id=325330 |
| 08:35 | <rniwa> | Ms2ger: hi Ms2ger! |
| 08:35 | <rniwa> | Ms2ger: lol |
| 08:35 | <Ms2ger> | I see you cc'd me on a bug :) |
| 08:35 | <rniwa> | Ms2ger: yeah |
| 08:36 | <rniwa> | Ms2ger: XML fragment parsing bug :( |
| 08:36 | <rniwa> | Ms2ger: it's such an edge case that I initially thought it's a bug in the test |
| 08:36 | <rniwa> | Ms2ger: but then Simon convinced me that it wasn't |
| 08:36 | <Ms2ger> | Dammit Simon :) |
| 08:36 | <rniwa> | Ms2ger: it's crazy I had to spend 2+ hours reading various parts of HTML5, DOM, & Parsing/Serialization specifications to figure it out |
| 08:37 | rniwa | is back |
| 08:37 | <Ms2ger> | ! |
| 08:37 | <rniwa> | Ms2ger: anyway, I was wondering if you could approve https://github.com/w3c/web-platform-tests/pull/456 ? |
| 08:37 | <rniwa> | MikeSmith: ^ |
| 08:37 | <rniwa> | it's a pretty straight forward fix for xhtml files |
| 08:38 | <Ms2ger> | Sure |
| 08:38 | <Ms2ger> | Ugh, CRLF |
| 08:39 | <rniwa> | Ms2ger: are we supposed to always use LF there? |
| 08:39 | <rniwa> | Ms2ger: I was almost going to fix it but I wasn't sure if it was policy. |
| 08:39 | <Ms2ger> | Vague policy :) |
| 08:39 | <Ms2ger> | Anyway, merged |
| 08:40 | <rniwa> | Ms2ger: I need to start merging tests for your parsing & serialization spec |
| 08:40 | <rniwa> | so that we can give a meaningful feedback |
| 08:40 | <rniwa> | s/merging/importing/ |
| 08:40 | <Ms2ger> | Yeah, I should probably put them into wpt |
| 08:40 | <Ms2ger> | Do you have a th.js test for that bug, btw? |
| 08:41 | <rniwa> | Ms2ger: what do you mean by th.js test? |
| 08:41 | <Ms2ger> | One that uses testharness.js |
| 08:41 | <rniwa> | Ms2ger: oh no. |
| 08:41 | <rniwa> | Ms2ger: I had assumed it exists somewhere |
| 08:41 | <rniwa> | Ms2ger: and I was hoping that you could tell me where it might be :( |
| 08:41 | <rniwa> | Ms2ger: but I could write one up if you want |
| 08:42 | <Ms2ger> | There's some tests in the spec repo |
| 08:42 | <Ms2ger> | But not at all exhaustive :) |
| 08:42 | <rniwa> | Ms2ger: could you move it to https://github.com/w3c/web-platform-tests/ ? |
| 08:42 | rniwa | can merge such a PR |
| 08:42 | <Ms2ger> | Yeah |
| 08:42 | <rniwa> | Ms2ger: that's why... |
| 08:42 | <rniwa> | Ms2ger: I was looking for those tests in that repo |
| 08:42 | <rniwa> | but couldn't find it :( |
| 08:42 | <Ms2ger> | I'll get to it :) |
| 08:42 | <rniwa> | Ms2ger: great. thanks. |
| 08:43 | <rniwa> | now I can announce on webkit-dev that we're the first major browser engine to pass the W3C tests for template elements :D |
| 08:45 | <Ms2ger> | Are they all wrong? ;) |
| 08:45 | <rniwa> | Ms2ger: they're all good :D |
| 08:45 | <rniwa> | Ms2ger: in fact, i've been fixing all those tests because they had a bunch of bugs like the one you just merged |
| 08:45 | <Ms2ger> | That seems implausible :) |
| 08:46 | <Ms2ger> | Unless you fixed them up first |
| 08:46 | <rniwa> | Ms2ger: I had to manually check each test case to make sure they're doing sensible things |
| 08:46 | <rniwa> | Ms2ger: you can check what i've done |
| 08:46 | <Ms2ger> | As always :) |
| 08:46 | <Ms2ger> | I'd rather not be sucked into that stuff :) |
| 08:46 | <rniwa> | Ms2ger: yeah |
| 08:47 | <rniwa> | Ms2ger: you'd better spend that time writing more spec, test, or doing other more useful things |
| 08:47 | <Ms2ger> | Indeed |
| 08:50 | <MikeSmith> | rniwa: you still needs me to do anything? |
| 08:51 | <rniwa> | MikeSmith: nope. Ms2ger took care of it for me :D |
| 08:51 | <MikeSmith> | k |
| 08:55 | rniwa | is going to enable template element by default on all webkit ports |
| 08:56 | <Ms2ger> | rniwa, so I'll try to look at the bug tonight |
| 08:58 | <hsivonen> | marcosc: for the "what exists" overview, it might be worthwhile to investigate IE, too, since, IIRC, IE comes the closest to using the metadata elements from the HTML spec |
| 08:58 | <marcosc> | hsivonen: yes, I've done a little bit of research |
| 08:59 | <marcosc> | I'll make sure it gets added |
| 08:59 | <marcosc> | there is a lot of use of <meta name="application-name"> |
| 08:59 | <marcosc> | I was impressed |
| 08:59 | <marcosc> | it's more popular than the apple equivalent |
| 09:06 | <hsivonen> | marcosc: any new recent exploration of installing apps to the homescreen but keeping the URL field available to the user somehow? (e.g. for copying tweet URLs) |
| 09:07 | <marcosc> | hsivonen: yeah, that's come up |
| 09:07 | <marcosc> | it might be some kind of option... "allow deep linking" or something |
| 09:08 | <marcosc> | but it might be that links might just work as normal, so you can long hold and copy a link |
| 09:08 | <marcosc> | hsivonen: there is also talk of enabling the user to access the address bar |
| 09:10 | <hsivonen> | oh so you'd long-hold the link on the view *previous* to the one you want to link to? |
| 09:12 | <hsivonen> | why did Apple create apple-mobile-web-app-title *after* application-name was in the spec? |
| 10:02 | <zcorpan> | annevk-cloud: what replaced "CORS-same-origin"? |
| 10:03 | <zcorpan> | annevk-cloud: see http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction |
| 11:02 | <zcorpan> | Hixie: is http://software.hixie.ch/utilities/js/live-dom-viewer/delayed-image supposed to have an empty body? |
| 11:56 | <hsivonen> | who operates web-sniffer.net and how does one report bugs to that person? |
| 12:02 | <annevk> | hsivonen: use http://redbot.org/ instead? |
| 12:38 | <hsivonen> | hmm. when reporting a WebKit security bug, most bugmail goes to @chromium.org |
| 13:31 | <philipj> | jgraham, ping |
| 14:00 | <jgraham> | philipj: Pong |
| 14:01 | <Ms2ger> | Did we hire philipj too? |
| 14:02 | <jgraham> | AFAIK no, he has just picked up bad irc habits from somewhere |
| 14:04 | <Ms2ger> | Oh, this isn't #ateam |
| 14:05 | <jgraham> | No, it isn't |
| 14:18 | <zcorpan> | annevk: what replaced "CORS-same-origin"? |
| 14:20 | <hsivonen> | marcosc: I sent an email to the manifest thread |
| 14:20 | <annevk> | zcorpan: the way it works now is that you get a response back and if you don't look behind the curtain (as some APIs such as <img> need to do) you can't really distinguish |
| 14:21 | <annevk> | zcorpan: I guess I should still have some kind of generic flag exposed so you can more easily determine whether to look behind the curtain |
| 14:22 | <zcorpan> | annevk: it's not obvious to me what i should say in cssom |
| 14:23 | <annevk> | zcorpan: I need more context |
| 14:23 | <zcorpan> | annevk: search for "cors-same-origin" in http://dev.w3.org/csswg/cssom/ |
| 14:25 | <annevk> | zcorpan: the first instance looks like a bug |
| 14:25 | <annevk> | zcorpan: and yeah, for the second instance we should probably have that kind of convenience flag |
| 14:26 | <zcorpan> | annevk: why is it a bug? |
| 14:27 | <annevk> | zcorpan: I think you only want to do that kind of thing for actual same-origin |
| 14:27 | <annevk> | zcorpan: not allow some kind of CORS opt-in to a quirk |
| 14:30 | <zcorpan> | annevk: ok. how do i do that? |
| 14:33 | <annevk> | zcorpan: I guess you'd compare document's origin with request's origin |
| 14:34 | <annevk> | zcorpan: would prolly be cleaner if response had a URL and origin associated with it too |
| 14:34 | <zcorpan> | annevk: what if it redirects? |
| 14:34 | <annevk> | zcorpan: request's origin is updated |
| 14:34 | <zcorpan> | ah |
| 14:34 | <annevk> | zcorpan: so you'd compare after the fetch finalizes |
| 14:34 | <annevk> | zcorpan: it's not entirely clear to me how stable all of that is though |
| 14:35 | <annevk> | nobody has really given feedback yet whether this is the right abstraction for what's going on in a browser :/ |
| 14:35 | <zcorpan> | annevk: ok. i'm not that familiar with the code in this area |
| 14:37 | <zcorpan> | annevk: thanks |
| 14:41 | <tj_vantoll> | Hi all, is it possible to respond to a mailing list thread from the digest email? I'm assuming that it's not but I wanted to check. |
| 14:43 | <tj_vantoll> | I'm basically wondering if there's a way to respond to a thread if I did not receive the actual email. |
| 14:43 | <annevk> | tj_vantoll: I think it's possible, but it's not super desirable as it breaks threading |
| 14:44 | <annevk> | tj_vantoll: if this is whatwg.org email, you can browse to the message in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ and then hit the first link (next to the author's name); that should open up your email client with the appropriate headers set |
| 14:44 | <annevk> | tj_vantoll: if it's w3.org email, you can do the same thing, but different |
| 14:45 | <jgraham> | In theory you could fix the threading headers by hand ofc |
| 14:45 | <tj_vantoll> | annevk: It's a whatwg one. I had no idea that that link would do that. |
| 14:46 | <tj_vantoll> | I guess I'll give that a shot and see what happens. Thanks! |
| 14:54 | <sangwhan> | Anyone know which spec was the first to introduce a redundant named color "grey" when there was already "gray"? |
| 14:55 | <sangwhan> | SVG seems suspicious, but not sure |
| 14:55 | <annevk> | sangwhan: I think that's a CSS thing |
| 14:59 | <SimonSapin> | CSS blames SVG: http://www.w3.org/TR/css3-color/#svg-color |
| 14:59 | <hsivonen> | does Blink-Opera really not have a character encoding override menu? |
| 15:00 | <hsivonen> | hooray, if so! |
| 15:00 | <sangwhan> | hsivonen: not on the checkout/branch I have, but lemme check the nightly |
| 15:01 | <sangwhan> | SimonSapin: Yeah, and SVG doesn't quite blame anyone - but why would they do that is beyond me |
| 15:02 | <SimonSapin> | bikeshedding |
| 15:02 | <jgraham> | X11 |
| 15:03 | <jgraham> | http://en.wikipedia.org/wiki/X11_color_names |
| 15:04 | <annevk> | Better add colour too |
| 15:04 | <sangwhan> | Copy the most impossible to use API on planet earth, well done :) |
| 15:04 | <SimonSapin> | Oh, we have a http://xkcd.com/978/ |
| 15:04 | <sangwhan> | Now time to implement background-colour |
| 15:04 | <SimonSapin> | W3C spec refers to wikipedia, which talks about what the W3C does |
| 15:04 | <annevk> | Do gray and grey serialize back in the same way? |
| 15:04 | <annevk> | That might require more bits than you'd want to give out |
| 15:04 | <hsivonen> | sangwhan: I sure hope Opera doesn't add that misfeature later |
| 15:05 | <SimonSapin> | I think colors serialize to #hex or rgb() |
| 15:05 | <annevk> | SimonSapin: even for specified style? |
| 15:05 | <sangwhan> | annevk: don't colors serialize to non-named? |
| 15:05 | <annevk> | sangwhan: well that's what I wanted them to do |
| 15:05 | <sangwhan> | one way to find out |
| 15:05 | <annevk> | but glazou made a lot of noise |
| 15:07 | <zewt> | hsivonen: if not that's a bug, encoding override isn't an optional thing |
| 15:07 | <zewt> | at least for people who aren't in japan occasionally trying to view pages that are, heh |
| 15:09 | <annevk> | SimonSapin: it'll prolly take a while for me to fix those URL bugs |
| 15:09 | <SimonSapin> | annevk: I know you’re busy |
| 15:10 | <annevk> | SimonSapin: yeah, these games don't play themselves |
| 15:11 | <darobin> | IIRC the grey/gray thing comes from an antique Netscape |
| 15:11 | <darobin> | it was supposed to make HTML easier to use for all authors |
| 15:11 | darobin | glad they didn't push that localise in all languages... |
| 15:11 | odinho | want grå, now! |
| 15:11 | <darobin> | or some story like that, I don't recall |
| 15:11 | <darobin> | it's certainly stupid enough to be a Netscape feature |
| 15:12 | <sangwhan> | Presto keeps it as grey and exposes that (but internally seems to use the raw color) and Blink seems to go whammo rgb() the moment it goes in |
| 15:12 | <philipj> | jgraham, I was going to ask about how to use assert_throws for exceptions which aren't DOMExceptions, but gave up instead |
| 15:12 | <SimonSapin> | spec says to serialize <color> with rgb() or rgba() http://dev.w3.org/csswg/cssom/#serialize-a-css-component-value |
| 15:12 | <SimonSapin> | Gecko, Blink and Presto do keywords: data:text/html,<body style=color:grEen><script>document.write(document.body.style.color)</script> |
| 15:12 | <philipj> | jgraham, the exception object thrown for "not enough arguments" doesn't have a code attribute |
| 15:13 | <hsivonen> | zewt: what's the deal with this being more of a problem in Japan than in Russia even though there's a greater number of Cyrillic legacy encodings? |
| 15:13 | <hsivonen> | zewt: broken windows effect? |
| 15:14 | <annevk> | hsivonen: what about CESU-8 btw? |
| 15:14 | <sangwhan> | SimonSapin: my tests conflict with your results on blink, although TC is a bit different |
| 15:14 | <annevk> | hsivonen: include that too? |
| 15:14 | <SimonSapin> | sangwhan: what’s your test case? |
| 15:14 | <jgraham> | philipj: You should be able to pass in an instance of the exception type as the first argument |
| 15:15 | <hsivonen> | annevk: I couldn't figure out why CESU-8 would be dangerous |
| 15:15 | <jgraham> | e.g. assert_throws(new TypeError(), function() {throw new TypeError()})) |
| 15:15 | <hsivonen> | annevk: and for the BMP, it seems useful to get to read it as UTF-8 |
| 15:16 | <sangwhan> | SimonSapin: document.querySelectorAll('body')[0].style.color='grey';alert(document.querySelectorAll('body')[0].style.color); |
| 15:16 | <annevk> | hsivonen: k |
| 15:16 | <annevk> | makes sense |
| 15:16 | <philipj> | jgraham, thanks! |
| 15:17 | <sangwhan> | hsivonen: nightlies don't have it either, but i don't know if the feature will make a comeback or not. not in the desktop team. |
| 15:18 | <SimonSapin> | sangwhan: wonderful. Blink uses rgb() for grey, but a keyword for grey |
| 15:18 | <SimonSapin> | a keyword for gray* |
| 15:18 | <annevk> | hsivonen: for what's worth, I am worried that there's pages out there that rely on the EBDIC label being ignored |
| 15:19 | <Ms2ger> | darobin, I thought that was x11 legacy |
| 15:19 | <hsivonen> | annevk: possible :-( |
| 15:19 | <Ms2ger> | I read an interesting post about the history of x11 at some point |
| 15:19 | <hsivonen> | annevk: getting telemetry for everything is so slow :-( |
| 15:19 | <darobin> | Ms2ger: IIRC it wasn't in Mosaic, but maybe that's named colours in general? — I don't know, it's been a long time |
| 15:20 | <hsivonen> | annevk: wouldn't such pages break in IE, then, though? |
| 15:20 | <Ms2ger> | "From notes it also seems some people was happy about this because they always forgot if it was grey or gray" |
| 15:20 | <sangwhan> | New Opera not having the encoding menu, not sure how that flies in Asia where encoding on every other website is broken beyond recognition though |
| 15:20 | <Ms2ger> | http://unix.stackexchange.com/questions/72919/what-are-the-origins-of-rgb-txt |
| 15:20 | <annevk> | hsivonen: fair point |
| 15:20 | <annevk> | hsivonen: if we only include the IE labels |
| 15:20 | <sangwhan> | SimonSapin: Hah, grey is different from gray? That's interesting |
| 15:21 | <SimonSapin> | that’s… I’m gonna go do something else now. |
| 15:21 | <hsivonen> | annevk: to serve the purpose of the mitigation, we should include all EBCDIC labels that ICU knows about |
| 15:23 | <sangwhan> | http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/programs/rgb/rgb.txt?rev=1.1 has too many shades of gray or grey, thank god that wasn't adopted... |
| 15:24 | <Ms2ger> | sangwhan, 50? |
| 15:28 | <sangwhan> | Ms2ger: moar |
| 15:28 | <sangwhan> | Well, enough with this grey nonsense, I'll do a in memory swap to gray when I see grey from now on |
| 15:29 | <jgraham> | Ms2ger: 236 shades of gr[e|a]y |
| 15:29 | <Ms2ger> | Noooooooo |
| 15:29 | <annevk> | hsivonen: alright, I'll collect those and report the datasets in the bug |
| 15:30 | <hsivonen> | annevk: thanks! |
| 15:37 | <annevk> | hsivonen: oh man, ICU is a disaster |
| 15:37 | <annevk> | hsivonen: try data:text/html;charset=ibm-17593,<script>alert(document.characterSet)</script> in Chrome |
| 15:38 | <Ms2ger> | Good thing that TC39 forced everyone to use it |
| 15:41 | <annevk> | # This is a special version of ibm-1140 that the XML4C (Xerces) parser team |
| 15:41 | <annevk> | # requested in 2000. |
| 15:41 | <annevk> | # It maps both EBCDIC LF and NL controls to Unicode LF U+000A. |
| 15:42 | <karlcow> | annevk, I have asked the person who reported the bug 304/CORS to give a more explicit code example and http sequence to explain how and when it fails. |
| 15:42 | <annevk> | karlcow: seems pretty clear no? |
| 15:42 | <annevk> | karlcow: sicking should've looked up the status code... |
| 15:44 | <karlcow> | I was surprised by sicking's answer ;) |
| 15:45 | <annevk> | hsivonen: ICU also supports labels such as ISO_2022,locale=ko,version=0 |
| 15:45 | <annevk> | hsivonen: if we were to take it into account we would have to do much more it seems |
| 15:48 | <hsivonen> | annevk: hmm. yeah, if that kind of labels get reflected to the Web, it's hopeless |
| 15:49 | <hsivonen> | annevk: I think that can't happen with ICU4J, though |
| 15:49 | <hsivonen> | annevk: I believe its label handling is what one would consider normal legacy |
| 15:49 | <annevk> | hsivonen: what is ICU4J and how do I get that data out of http://demo.icu-project.org/icu-bin/convexp ? |
| 15:50 | <annevk> | hsivonen: but see the Chrome example I gave earlier, it gives utf-8 for that |
| 15:50 | <annevk> | hsivonen: rather than iso-8859-1 |
| 15:50 | <hsivonen> | annevk: yeah, that ibm-17593 thing is very, very sad |
| 15:51 | <hsivonen> | annevk: ICU4J is the Java version of ICU. |
| 15:52 | <annevk> | hsivonen: okay, so that exposes a lot less labels and encodings |
| 15:53 | <annevk> | hsivonen: but if that's safe :/ |
| 15:54 | <hsivonen> | annevk: http://source.icu-project.org/repos/icu/icu4j/trunk/main/classes/charset/src/com/ibm/icu/charset/UConverterAliasDataReader.java gives a hint of what file to look for in the repo |
| 15:54 | <annevk> | hsivonen: the file is http://source.icu-project.org/repos/icu/icu/trunk/source/data/mappings/convrtrs.txt |
| 15:54 | <annevk> | hsivonen: which as you can see has many mappings for utf-8 |
| 15:55 | <hsivonen> | ಠ_ಠ at Chrome just exposing ICU alias data to the Web |
| 15:55 | <annevk> | data:text/html;charset=windows-65001,<script>alert(document.characterSet)</script> is utf-8 too in Chrome |
| 15:55 | <gsnedders> | hsivonen: CESU-8 allows non-shortest-form null, no? So might break with some sanitizers… |
| 15:55 | <hsivonen> | not cool. bad Chrome. |
| 15:56 | <hsivonen> | gsnedders: oh. I didn't know that. I thought only Java "modified UTF-8" did that |
| 15:56 | <annevk> | where is jsbell |
| 15:56 | <gsnedders> | hsivonen: There was a reason for my "no?" at the end, I thought that was part of the CESU-8 too? |
| 15:56 | <gsnedders> | hsivonen: I could, of course, be wrong :) |
| 15:57 | <gsnedders> | hsivonen: I am wrong. |
| 15:57 | <hsivonen> | ok |
| 15:58 | <annevk> | gsnedders: "CESU-8 is similar to Java's Modified UTF-8 but does not have the special encoding of the NUL character (U+0000)." |
| 15:58 | <gsnedders> | I was just typing that. |
| 15:58 | <gsnedders> | (It is, notably, the only difference between the two) |
| 16:05 | <annevk> | hsivonen: Safari does the same for ICU |
| 16:16 | <annevk> | tj_vantoll: btw, if you have Gmail I recommend switching from digest and just using a filter |
| 16:17 | <annevk> | hsivonen: filed bugs on Chrome and Safari |
| 16:17 | <annevk> | hsivonen: not entirely sure what to do for the replacement encoding now |
| 16:17 | <tj_vantoll> | annevk: I just did thanks. |
| 16:18 | <Hixie> | GPHemsley: thanks |
| 16:22 | <JonathanNeal> | Mornin' (Pacific) |
| 16:26 | <Hixie> | zcorpan: fixed |
| 16:26 | <Hixie> | GPHemsley: btw, anne is right that we don't necessarily need to respond to everything. it's like the story of the new bar vs the old bar, where the old bar has a bunch of notices up for random stuff its customers have done over the years. |
| 16:27 | <Hixie> | GPHemsley: it may simply be better to live with the occasional person having trouble, and help them personally rather than with a notice |
| 16:27 | GPHemsley | is not familiar with said story |
| 16:27 | <Hixie> | marcosc: i'm unclear on what problem this is solving |
| 16:28 | <annevk> | GPHemsley: you go to the new bar because it has less bullshit bothering you |
| 16:28 | <Hixie> | GPHemsley: the old bar will have signs like "no backpacks on tables" because one day twenty years ago, some guy put his backpack on a bar and knocked a drink over, or whatever |
| 16:29 | <Hixie> | GPHemsley: which is a pointless sign really :-) |
| 16:29 | GPHemsley | doesn't go to bars |
| 16:29 | <Hixie> | well me either |
| 16:30 | <Hixie> | but the point is just that there's a cost to putting signs up for every last thing |
| 16:30 | <Hixie> | (and people dont read long signs anyway) |
| 16:30 | <GPHemsley> | ok |
| 16:30 | <GPHemsley> | like I said, I'll revisit it later |
| 16:31 | <Hixie> | lgtm |
| 16:31 | <Hixie> | i'm not particularly worried about the notices myself |
| 16:31 | <Hixie> | just wanted to make sure the faq didn't scare people off :-) |
| 16:32 | <GPHemsley> | I think the FAQ will scare people off with or without the notices :P |
| 16:32 | <GPHemsley> | it's humongous |
| 16:32 | <Hixie> | well, true |
| 16:32 | <Hixie> | but gotta give it a chance :-) |
| 16:33 | <GPHemsley> | were there any other pages that you wanted the notice removed from? |
| 16:33 | <GPHemsley> | (or, like I said, you can take care of it yourself) |
| 16:33 | <Hixie> | nah, i only send people to the faq :-) |
| 16:34 | <GPHemsley> | k |
| 16:34 | <GPHemsley> | annevk: In the meantime, you should now be able to set up a user style that removes the notice |
| 16:35 | <Hixie> | bbiab |
| 16:41 | <annevk> | GPHemsley: thanks, but I try not to change my default setup |
| 16:41 | <annevk> | GPHemsley: makes it harder to reproduce bugs |
| 16:41 | <GPHemsley> | very well |
| 17:06 | <Hixie> | annevk: just logging in removes them too :_) |
| 17:09 | <annevk> | Hixie: I'm in permanent private mode on my phone |
| 17:09 | <annevk> | Hixie: and also, I'm more concerned about other people than myself here, I can cope |
| 17:11 | <Hixie> | "permanent private mode"? |
| 17:50 | <dglazkov> | good morning, Whatwg! |
| 19:29 | <zcorpan> | TabAtkins: did you flesh out something with <picture>? |
| 19:53 | <zcorpan> | hmm, the web component thread became emotional. maybe it needs ice cream |
| 21:13 | <annevk> | zcorpan: actual ice cream or a metaphor? |
| 21:16 | <zcorpan> | 🍨 |
| 21:16 | <Ms2ger> | Ice cream vas |
| 21:16 | <Ms2ger> | vans |
| 21:16 | <annevk> | "Your search - 🍨 - did not match any documents." |
| 21:24 | <gsnedders> | Ms2ger: don't end up with people dead people of ice cream vans! |
| 21:24 | <gsnedders> | (Context: http://en.wikipedia.org/wiki/Glasgow_Ice_Cream_Wars) |
| 21:50 | <zcorpan> | annevk: https://duckduckgo.com/?q=🍨 |
| 23:43 | <Hixie> | dglazkov: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0454.html is hard to read because of all the cuteness :-/ |
| 23:59 | <dglazkov> | Hixie: your argument is invalid |