| 03:22 | <TabAtkins> | Hixie_: Re: Map and Set and structured clone, spec plz |
| 03:23 | <TabAtkins> | GPHemsley: Regarding your pseudo-element question, no. There's been proposals, but implementors in general don't seem keen to do heavy box-tree rewriting like that. |
| 06:15 | <zcorpan> | hmmm, i have no idea how to spec http://lists.w3.org/Archives/Public/www-style/2013Oct/0508.html |
| 06:16 | <zcorpan> | presumably the same applies to 'scroll' |
| 06:18 | <zcorpan> | several documents can resize or scroll at the same time, too. what should scripts see when you resize a page with a 50% width iframe, and the 'resize' event has fired in the iframe but not on the outer page yet? |
| 06:18 | <zcorpan> | i guess the updated state in the iframe and the old state in the outer page? |
| 07:49 | <zcorpan> | respec inception? http://darobin.github.io/html-ruby/snapshots/FPWD.html |
| 08:11 | <MikeSmith> | zcorpan: that's the special "emphasis" feature that Robin added |
| 08:12 | <MikeSmith> | it causes everything to be repeated twice for extra emphasis |
| 08:23 | <zcorpan> | nice |
| 08:23 | <zcorpan> | nice |
| 08:33 | <jgraham> | heh |
| 08:33 | <jgraham> | heh |
| 08:51 | <zcorpan> | matjas: "the second string uses two separate code points (U+00F1 LATIN SMALL LETTER N WITH TILDE and U+0303 COMBINING TILDE)" you mean U+006E |
| 08:51 | <zcorpan> | http://mathiasbynens.be/notes/javascript-unicode |
| 08:53 | <zcorpan> | doesn't NFC still have some stuff decomposed? |
| 08:53 | <matjas> | zcorpan: ah, copy-paste fail, thanks for the heads up |
| 08:54 | <matjas> | zcorpan: it leaves some stuff decomposed (see next example) but afaik never if there is a single-code point alternative |
| 08:55 | <JakeA> | Anyone know a url to a large resource/page that has an open CORS header? |
| 08:55 | <zcorpan> | right. *continues reading* |
| 08:55 | <zcorpan> | JakeA: how large? |
| 08:55 | <JakeA> | oh and also gzipped |
| 08:56 | <JakeA> | urm, upwards of 1mb? |
| 08:56 | <JakeA> | I should just upload one, but I'm being lazy |
| 08:57 | <JakeA> | looking for something large enough to trigger multiple xhr progress events on most connections |
| 08:57 | <JakeA> | actually, I'll just upload one |
| 08:58 | <zcorpan> | JakeA: validate the html spec with http://validator.nu and check 'show source' |
| 08:58 | <zcorpan> | dunno if it gzips though |
| 09:00 | <JakeA> | zcorpan: It does! Excellent, thanks! |
| 09:01 | <JakeA> | The html spec was the first thing I tried but no cors. validator.nu works fine, excellent. |
| 09:02 | <zcorpan> | i guess if you validate the html spec very often, hsivonen will be grumpy and block your IP or something :-P |
| 09:03 | <JakeA> | it's for a crbug ticket, so hopefully low traffic |
| 09:16 | <MikeSmith> | I think http://html5.validator.nu/ handles load better and is more reliable than http://validator.nu |
| 09:17 | <MikeSmith> | fwiw |
| 09:19 | <MikeSmith> | zcorpan: at this point the stance in your response to porneL about <picture> doesn't seem like a specific stance against <picture> but more of general argument against adding new elements if the same problem could be solved by adding an attribute instead |
| 09:19 | <JakeA> | MikeSmith: Cheers. Already closed the ticket so it's ok now. |
| 09:19 | <MikeSmith> | JakeA: k |
| 09:20 | <zcorpan> | MikeSmith: yeah |
| 09:20 | <michou> | hello :) |
| 09:20 | <MikeSmith> | zcorpan: so far noboby except you has responded in substance to porneL's proposed revision to the <source>-selection algorithm |
| 09:20 | <michou> | any full-screen guru's around? :) |
| 09:22 | <zcorpan> | MikeSmith: i noticed that <input list=""> where we introduced elements for an existing feature without losing the reuse |
| 09:22 | <zcorpan> | although having to maintain IDs is a drawback |
| 09:24 | <yoav> | zcorpan: So you see a possibility where adding <picture> won't involve adding a massive amount of tests? |
| 09:25 | <zcorpan> | yoav: see http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html |
| 09:25 | <yoav> | zcorpan: So the answer is no :) |
| 09:27 | <yoav> | zcorpan: That's what I thought, just wanted to make sure |
| 09:27 | <zcorpan> | right. porneL's proposal is a big improvement because it makes testing the selection algorithm itself on par with srcset, but that doesn't change the lack of reuse for all other things |
| 09:28 | <zcorpan> | consider if we had done <inputwithdatalist> <option> </inputwithdatalist> instead of <input list=x> <datalist id=x> <option> </datalist> and what the consequence would be for <inputwithdatalist>'s RTL support, for instance |
| 09:30 | <zcorpan> | that doesn't mean that reusing an element is always the right answer. it needs to be considered on a case-by-case basis, i think |
| 09:31 | <zcorpan> | maybe the existing element is so horrible that it's a good idea to have a clean break |
| 09:31 | <yoav> | zcorpan: A crazy thought - Would it be possible to alias picture to img, with the only difference is that picture is not a self closing element? |
| 09:31 | <MikeSmith> | I can understand the massive-amount-of-tests argument against <picture> but I have a hard time seeing that as something that should take priority over trying to come up with the least error-prone solution for authors if possible |
| 09:32 | <yoav> | That way we get all of img's functionality for free, than add source children |
| 09:33 | <MikeSmith> | I would argue that src-N and srcset too just move the massiveness of the problem off onto authors, in terms of the costs it places on how ever many hundreds of thousands of authors making more mistakes with it over how ever many years |
| 09:33 | <MikeSmith> | yoav: that aliasing doesn't sound so doable to me but who knows |
| 09:34 | <yoav> | MikeSmith: Probably not. As I said - crazy thought |
| 09:34 | <Ms2ger> | Eww |
| 09:34 | <zcorpan> | yoav: i think there can be code reuse, but most likely it would involve refactoring and refactoring most likely means new regressions |
| 09:35 | <zcorpan> | yoav: also, it wouldn't enable rich fallback |
| 09:35 | <zcorpan> | yoav: if you want rich fallback, you have to redesign the fallback mechanism |
| 09:37 | <zcorpan> | anyway, i don't really mean to shoot <picture> in the head, i just want to point out the costs so we can do a reasonable cost/benefit analysis |
| 09:37 | <yoav> | zcorpan: I'm mainly thinking of test reuse, rather than code reuse. Picture's implementation is not that scary. Rewriting half the platform's tests is. |
| 09:38 | <yoav> | zcorpan: I don't understand why aliasing won't enable rich fallback. |
| 09:39 | <zcorpan> | yoav: i assumed that if you did a real alias, then the fallback mechanism would use the alt="" attribute |
| 09:39 | <yoav> | zcorpan: I 100% agree with the need for a cost/benefit analysis |
| 09:40 | <yoav> | zcorpan: At first yes, but maybe it can be extended when the element is not self closing. |
| 09:40 | <zcorpan> | yoav: i don't understand what you have in mind for test reuse |
| 09:42 | <yoav> | zcorpan: I don't have a clear vision yet (a crazy though, as I said), but if picture is an alias of img, there may not be a need to test non-picture-specific functionality for it |
| 09:42 | <yoav> | zcorpan: Not sure that's true, just throwing it out there |
| 09:43 | <yoav> | the fact that it's not a real alias, but an extended one, may make it impossible |
| 09:45 | <zcorpan> | yoav: ok. i wouldn't trust that the aliasing doesn't have bugs, so my knee-jerk reaction is that we would need to test it anyway. but such testing doesn't need to block shipping the thing |
| 09:45 | jgraham | doesn't quite understand what "alias" means in this discussion |
| 09:45 | <MikeSmith> | zcorpan: about https://www.w3.org/Bugs/Public/show_bug.cgi?id=23568 (<ul><script>) I implemented support for that at a long time ago. If it7s getting reported to somebody as an error I think it's probably because it hasn't been pulled to html5.validator.nu and validator.nu yet |
| 09:45 | <jgraham> | Is it "alias" in the sense that <image> is an alias of <img>? |
| 09:46 | <zcorpan> | jgraham: no |
| 09:46 | <yoav> | jgraham: Exactly |
| 09:46 | <jgraham> | heh |
| 09:46 | <zcorpan> | LOL |
| 09:46 | <yoav> | zcorpan: :) |
| 09:46 | <yoav> | That's what I was thinking when I said "aliasing" |
| 09:46 | <zcorpan> | the html parser creates an "img" element out of an <image> tag |
| 09:46 | <zcorpan> | surely you don't want <picture> to *become* img in the DOM? |
| 09:47 | <Ms2ger> | Now, how do you serialize an img element with children? |
| 09:48 | <zcorpan> | (also, <image> doesn't have children) |
| 09:49 | <jgraham> | Even if you just meant that picture implements HTMLImageElement, it seems very messy |
| 09:49 | <zcorpan> | MikeSmith: if it's implemented, feel free to close the bug |
| 09:49 | <MikeSmith> | ok just did. I'll remind hsivonen to pull |
| 09:49 | <yoav> | zcorpan, Ms2ger: Yeah, probably a bad idea |
| 09:50 | <yoav> | I was just thinking that if <img> wasn't self-closing, it could have been extended by its children, without the need to add a new element for it |
| 09:52 | <zcorpan> | it is, and we can't change it. well, i guess technically we could change it by switching on an attribute, but that's messed up :-) |
| 10:05 | <zcorpan> | another thing to keep in mind is that what we're after now is probably a stop-gap measure, the real long-term solution might be something like http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0072.html |
| 10:07 | <jgraham> | Pretty sure the long term solution is http://twistedspeedo.com/?p=1012 |
| 10:11 | <yoav> | zcorpan: I agree file format is the long term solution (not sure about JP2K though), but the gap would be pretty long |
| 10:18 | <zcorpan> | btw is anyone working on improving jpeg encoders these days? |
| 10:19 | <Ms2ger> | Don't think so |
| 10:22 | <annevk> | Kornel seems to be |
| 10:23 | <zcorpan> | https://github.com/pornel/jpeg-compressor ? |
| 10:31 | <yoav> | zcorpan: Yeah |
| 10:31 | <zcorpan> | nice. pornel++ |
| 10:42 | <MikeSmith> | haha 'Codename "Nether Poppleton"' |
| 10:42 | <MikeSmith> | pornel rocks mightily |
| 10:42 | <MikeSmith> | the Web needs more pornel |
| 10:59 | <annevk> | matjas: I recommend reading up on grapheme clusters if you haven't already |
| 10:59 | <annevk> | matjas: http://www.unicode.org/reports/tr29/ |
| 10:59 | <annevk> | matjas: if you want proper Unicode support in JavaScript, that's probably where we should be looking for inspiration |
| 11:17 | <jgraham> | odinho: Holy fast review batman :) |
| 11:34 | <SimonSapin> | matjas: http://mathiasbynens.be/notes/javascript-unicode "U+00F1 LATIN SMALL LETTER N WITH TILDE and U+0303 COMBINING TILDE" seems wrong |
| 11:35 | <SimonSapin> | matjas: the first should be U+004E |
| 11:36 | <Ms2ger> | SimonSapin, not 6E? |
| 11:36 | <Ms2ger> | http://krijnhoetmer.nl/irc-logs/whatwg/20131021#l-149 |
| 11:37 | <SimonSapin> | Ms2ger: right |
| 12:59 | <zcorpan> | hmm, fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23566 means i have to talk about what the `options` should be when there are no arguments |
| 13:06 | <zcorpan> | would be nicer with webidl having [TreatUndefinedAs=false] |
| 13:06 | <zcorpan> | heycam: ^ |
| 13:07 | <heycam> | zcorpan, can you not do that with an optional argument default value? |
| 13:07 | <heycam> | or is it not optional |
| 13:07 | <zcorpan> | default value is true |
| 13:08 | <heycam> | but explicit undefined needs to be false? |
| 13:08 | <zcorpan> | yeah |
| 13:08 | <heycam> | tbh I'd say "use any and define it in prose" :) |
| 13:09 | <heycam> | like anne [TreatUndefinedAs] is kind of ugly |
| 13:09 | <heycam> | I wonder if any current uses of it can be replaced by optional arguments with default values |
| 13:09 | <heycam> | s/anne/anne I think/ |
| 13:09 | <zcorpan> | i agree it's ugly |
| 13:10 | <zcorpan> | but what i have now is also ugly |
| 13:10 | <zcorpan> | <li><p>If invoked with no arguments, let <var>top</var> be true and let <var>options</var> be a <code>ScrollOptions</code> dictionary with its members not |
| 13:10 | <zcorpan> | present or present with the default value, as appropriate. |
| 13:10 | <zcorpan> | how does any+prose help? |
| 13:11 | heycam | looks at the spec to see the actual signature |
| 13:11 | <zcorpan> | i haven't committed yet |
| 13:12 | <heycam> | the current signature |
| 13:12 | <zcorpan> | void scrollIntoView(); |
| 13:12 | <zcorpan> | void scrollIntoView(boolean top, optional ScrollOptions options); |
| 13:13 | <heycam> | so you add the no-arg version, so that it can have a different value for 'top' |
| 13:13 | <heycam> | effectively |
| 13:13 | <zcorpan> | right |
| 13:13 | <heycam> | but then when you describe in prose how to handle a no-arg invocation, you need to talk about a ScrollOptions that you make up |
| 13:13 | <heycam> | ok |
| 13:13 | <heycam> | what about just having: |
| 13:14 | <heycam> | void scrollIntoView(optional boolean top, optional ScrollOptions options); |
| 13:14 | <heycam> | and describe what to do when top is missing? |
| 13:14 | <heycam> | probably results in overall less prose |
| 13:14 | <zcorpan> | that means explicit undefined is the same as missing |
| 13:14 | <heycam> | ah |
| 13:14 | <heycam> | then you use any |
| 13:15 | <heycam> | I guess :) |
| 13:15 | <heycam> | otherwise, no good suggestions atm |
| 13:15 | <zcorpan> | i don't understand the any suggestion |
| 13:17 | <heycam> | you make top 'any', then write in prose how to handle undefined, and in all other cases invoke ToBoolean |
| 13:18 | <heycam> | still, it's probably nicer to keep it as boolean |
| 13:18 | <heycam> | makes the IDL more informative, even if you do need to mess around with the ScrollOptions thing in prose |
| 13:21 | <zcorpan> | any and optional? |
| 13:22 | <heycam> | ah yeah |
| 13:23 | <zcorpan> | anyway yeah i'll keep it as boolean |
| 13:48 | <annevk> | whoa, heycam is in Europe again |
| 13:50 | <annevk> | zcorpan: can't you make omitted also false? |
| 13:51 | <annevk> | zcorpan: seems better if undefined and omitted keep the same semantics unless it's a really special situation |
| 13:54 | <heycam> | annevk, enjoying the paris office this week |
| 13:54 | <annevk> | was thinking you would |
| 13:54 | <annevk> | what has IDL to do with rendering again? ;p |
| 13:55 | <zcorpan> | annevk: changing how scrollIntoView() works seems to have a much bigger impact than changing how scrollIntoView(undefined) works |
| 13:55 | <annevk> | zcorpan: doesn't scrollIntoView() default to false in WebKit atm? |
| 13:55 | heycam | hides |
| 13:56 | <darobin> | that's all a lie annevk |
| 13:56 | <darobin> | if heycam were in Paris, he'd wave or something, you know |
| 13:57 | <zcorpan> | annevk: no |
| 13:57 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2572 |
| 13:57 | <zcorpan> | undefined: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2573 |
| 13:58 | heycam | waves, and assumes darobin must have hacked into all the CC cameras in the city to be able to see it |
| 13:59 | darobin | waves at the computer, assumes some form of transmission |
| 14:00 | <annevk> | fucking merge conflicts |
| 14:00 | annevk | blames Ms2ger |
| 14:41 | <SimonSapin> | darobin: http://lists.w3.org/Archives/Public/spec-prod/2013OctDec/0029.html +1 |
| 14:41 | <SimonSapin> | darobin: how do we start moving towards this? |
| 14:42 | <darobin> | SimonSapin: a small first step is to say +1 on the list too so that it is seen to be supported |
| 14:42 | <darobin> | beyond that, I want to confer with people who work on publication inside the Team to see if we can get this off the ground relatively quickly |
| 14:43 | <SimonSapin> | cool |
| 14:43 | <darobin> | it in fact does not really require any change to the Process as far as I can tell |
| 14:43 | <darobin> | most importantly, it matches the needs of the patent policy, which is a nightmare to change |
| 14:43 | <darobin> | glad you like it :) |
| 14:51 | <jgraham> | Romantic interests? Since we don't have any good way to tell who any given person might be *interested* in romantically, that suggests we have to spam the entire planet. Maybe it would just be easier to get non-conformance to pubrules brought up at the UN? |
| 14:52 | <darobin> | no, we just place editors under a requirement to disclose romantic interests |
| 14:53 | <jgraham> | Hmm, suddenly I thik we won't have any editors under your plan :) |
| 14:53 | <darobin> | then anyone they sleep with not previously registered gets informed that, clearly, they were just a one-night-fling due to excess alcohol consumption |
| 14:53 | <darobin> | I don't mind disclosing my romantic interest :) |
| 14:54 | <jgraham> | Oh, if "interest" just means "have slept with", that makes things easier |
| 14:54 | <darobin> | we're going to need a standard for that |
| 14:54 | <jgraham> | If "interest" means "are interested in", it could cause all sorts of strife |
| 14:54 | <darobin> | precisely |
| 14:54 | <darobin> | wait |
| 14:54 | <darobin> | standards aren't about creating strife? |
| 14:55 | <jgraham> | I think that's just a secondary effect |
| 14:55 | <darobin> | I have a lot of a empirical evidence showing that it's the primary effect :) |
| 14:55 | <jgraham> | AIUI standards are mostly about propping up Hollywood |
| 14:56 | <darobin> | and that is different from deliberately creating strife in which ways exactly? |
| 14:57 | <jgraham> | Well I guess the point of propping up business models is to make money for people in those businesses. This leads to societial inequality between those who have money and those who don't. Which causes strife and, if left unchecked, eventual revolution |
| 14:57 | <jgraham> | So standards are all about revolution and that's why there's so many French people involved |
| 15:04 | <darobin> | heh |
| 15:45 | <annevk> | kinda wonderful how much text from XMLHttpRequest is now obsolete |
| 15:45 | <annevk> | kinda scary how much will regress here |
| 15:56 | <Hixie_> | annevk: Map and Set structured clone -- should I do it, or is JS gonna have a definition soon? |
| 15:57 | <annevk> | Hixie_: since it isn't much effort, might as well do it in HTML for now |
| 15:57 | <Hixie_> | k |
| 15:58 | <annevk> | Hixie_: structured clones are not going to make it into ES6 I think, multiple globals aren't either by the looks of it :/ |
| 15:58 | <Hixie_> | what does "ES6" mean? 2013? |
| 15:59 | <annevk> | "stable draft" end-of-2013, "standard" end-of-2014 |
| 15:59 | <Hixie_> | wow, no new JS features between end of 2013 and end of 2014? |
| 16:00 | <annevk> | Hixie_: well since we have ES6 features now, we'll have ES7 features such as Object.observe() sooner than ES7 |
| 16:00 | <Hixie_> | wait, Object.observe() isn't "stable"? |
| 16:00 | <Hixie_> | i thought people were implementing that already |
| 16:00 | <annevk> | Hixie_: in addition, TC39 decided to move to a more iterative process for individual features so they can be considered done before the overall spec is "done" |
| 16:01 | <annevk> | Hixie_: yeah, but not shipping |
| 16:01 | <Hixie_> | why not shipping? |
| 16:01 | <Hixie_> | only one more step to a living standard... |
| 16:01 | <annevk> | Hixie_: so yeah, the new iterative thing will allow shipping by declaring consensus sooner than "standard" |
| 16:02 | <annevk> | Hixie_: and indeed, it's more or less the same, with some kind of committee approval steps in between, which seem awkward, but given the way JavaScript is developed I don't immediately see a better way |
| 16:02 | <Hixie_> | the difference between "consensus" and "standard" is what again? :-) |
| 16:02 | <Hixie_> | on another note, what's that CSS property that defines how replaced content gets sized |
| 16:02 | <annevk> | Hixie_: "standard" is what's Ecma-approved |
| 16:02 | <Hixie_> | i thought it was image-fit, but seems not |
| 16:02 | <annevk> | Hixie_: "consensus" is TC39-approved |
| 16:03 | <Hixie_> | annevk: what's the word they use for "browser shipped interoperably"? |
| 16:03 | <annevk> | Hixie_: "legacy" :p |
| 16:03 | <Hixie_> | (ah, object-fit) |
| 16:03 | <annevk> | (I'm not sure. They consider it de facto and something they need to define without breaking things.) |
| 16:03 | <Hixie_> | annevk: ok so when will structured clone in JS be "legacy"? :-) |
| 16:04 | <annevk> | Ah, so the other thing is that they like the platform <-> language separation a bit too much. So saying workers and such are part of their world can be a hard sell depending on who you talk to. Though most implementers people are on board. |
| 16:05 | <jgraham> | Hixie_: Once browsers ship it interoperably :) |
| 16:05 | <annevk> | implementer people* |
| 16:05 | <Hixie_> | jgraham: well, i meant when will they have a spec that describes reality that i can defer to |
| 16:05 | <Hixie_> | but it sounds like "not soon", so, nevermind |
| 16:06 | <jgraham> | There are two states a) future things that don't ship yet and b) distasteful legacy |
| 16:06 | Hixie_ | realises he still hasn't made HTML properly integrate with css-images and the "CSS⇋Object Negotiation" protocol |
| 16:06 | <Hixie_> | jgraham: sounds right |
| 16:07 | <Hixie_> | hm, there's no default default object size, huh |
| 16:09 | <Hixie_> | ok, browsers are off in lala land again. |
| 16:09 | <Hixie_> | default size for svg seems to be "100% of container" |
| 16:11 | <Hixie_> | TabAtkins: ping (how do i integrate with css-images for <img> containing svg without intrinsic dimensions but with an intrinsic ratio? it looks like i need to give you some sort of "fit the containing block width" information as the default object size for <img>, or something) |
| 16:11 | <gsnedders> | So what's the best way to deal with a bug that makes Fennac unusable for me on my tablet, but I can't quite reproducably hit it? |
| 16:13 | <Hixie_> | gsnedders: keep trying to reproduce it? :-) |
| 16:13 | <Hixie_> | this on android? |
| 16:13 | <gsnedders> | Yeah. |
| 16:13 | <Hixie_> | take a debug log when it happens, maybe that might help |
| 16:13 | <gsnedders> | Often doesn't respond to input for several seconds. |
| 16:14 | <Hixie_> | TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23581 |
| 16:23 | <Domenic_> | Hixie_: annevk: one thing to keep in mind is that there's a difference between "consensus on a strawman" and "we nailed down all the details in spec language." Part of the proposed ES7 process is to get formal spec text earlier to get all the interoperability edge cases nailed out. |
| 16:23 | <Hixie_> | you can't nail down all the details until after at least one, probably several, implementations have shipped. |
| 16:24 | <Hixie_> | but certainly formal text should be early in the process |
| 16:24 | <Hixie_> | because trying to describe something formally is step one in trying to figure out if the proposal makes any sense |
| 16:27 | <dglazkov> | good morning, Whatwg! |
| 16:30 | <Domenic_> | Does anyone know why Chrome now returns HTMLElement for document.createElement('image')? Seems weird to intentionally diverge JS API and the HTML parser? http://src.chromium.org/viewvc/blink?view=revision&revision=159920 |
| 16:31 | <Domenic_> | I guess there are already divergences (e.g. createElement throwing for certain element names), but, what motivated this? |
| 16:31 | <Hixie_> | "now"? didn't it always/ |
| 16:31 | <Hixie_> | ? |
| 16:31 | <Hixie_> | it should be HTMLUnknownElement, I _think_ |
| 16:32 | <Hixie_> | for 'image' in createElement |
| 16:32 | <Hixie_> | per the spec |
| 16:32 | <annevk> | Domenic_: the parser creates an element for a namespace, name, and a set of attributes |
| 16:33 | <annevk> | Domenic_: having the special case in "creates an element" seems weird |
| 16:34 | <Domenic_> | annevk: not sure I understand... I am trying to see why the parser doesn't just do document.createElementNS(parsedName, parsedNS) |
| 16:35 | <annevk> | Domenic_: well for one, those are distinct |
| 16:36 | <annevk> | Domenic_: but e.g. otherwise the pre-scanner would miss out on this alias |
| 16:37 | <Domenic_> | hmm this seems to involve more things than i understand. i think i will attempt to retreat from this line of questioning and come back later when I learn more. |
| 16:37 | <Hixie_> | Domenic_: it does, except for <image> and <isindex> and a few other weird cases |
| 16:38 | <Domenic_> | Hixie_: <isindex> is weird, I can understand weird stuff being necessary. What's the deal with <image>? |
| 16:38 | <Hixie_> | <image> has to be treated like <img> because 5 years ago, 0.2% of pages used <image> and expected it to work like <img>. |
| 16:39 | <Domenic_> | right, but, why is the parser different from createElement? |
| 16:39 | <Domenic_> | Hmm maybe createElement is trying to be sane but the parser can't afford to? |
| 16:39 | <Hixie_> | right |
| 16:39 | <Domenic_> | Got it, thanks |
| 16:39 | <Hixie_> | we try to limit the scope of quirks |
| 16:41 | <annevk> | createElement("x*") -> throws |
| 16:41 | <annevk> | <x*> -> works |
| 16:41 | <Domenic_> | right, is that the same principle, that createElement can afford to enforce rules, but the parser cannot? |
| 16:43 | <annevk> | Hah, I don't really know who designed these APIs, but I doubt much of principles were involved we would use today. |
| 16:43 | <Domenic_> | fair :P |
| 16:44 | <Domenic_> | my interest is that in jsdom we weren't able to use the actual DOM elements to build the DOM tree because of situations like this |
| 16:44 | <Domenic_> | we needed to provide a "privileged" createElement that the parser could use |
| 16:44 | <Domenic_> | which was kind of sad |
| 16:44 | <annevk> | Restrictions in createElement() are influenced by XML. And in a weird way. createElement() follows Name whereas createElementNS() follows NCName. Although both create namespaced elements today... |
| 16:45 | <Domenic_> | Yeah, I remember following those links... fun times. |
| 16:45 | <jgraham> | Actually the parser can never create an element named "image" in the HTML namespace, so that isn't an example of "createElement can't, parser can" |
| 16:48 | <annevk> | Even in <template>! |
| 16:49 | <Domenic_> | jgraham: good point. I confused myself, and was trying to think of createElement('tagname') as parseHTML('<tagname>'). But it's better to think of parseHTML as using createElement, modulo XML-influenced restrictions. |
| 16:50 | <annevk> | The parser cannot really use createElement() directly anyway. It wants something else for saner mutation records. |
| 16:51 | <Domenic_> | ah interesting |
| 16:51 | <annevk> | Not entirely sure what, prolly something close to what browsers have internally, although that might not be ideal either. |
| 16:52 | <annevk> | And I believe currently some stuff in the HTML specification depends on elements being created having their relevant attributes set straight away. |
| 16:52 | <annevk> | So createElement() does not work for that either. |
| 16:55 | <Hixie_> | yup |
| 16:56 | <Hixie_> | Domenic_: all these features were designed by different people with different priorities and philosophies |
| 16:56 | <Hixie_> | some of which were things like "my boss is breathing down my neck about this other property needing this feature before friday so he can go golfing" |
| 16:56 | <Hixie_> | (property as in, web site owned by the vendor's company) |
| 17:18 | <TabAtkins> | Hixie_: Just pass the ratio as the intrinsic dimensions. (The dimensions are width/height/ratio.) And then, yes, set up the default image size as the size of the <img>. |
| 17:19 | <Hixie_> | "set up the default image size as the size of the <img>"? |
| 17:19 | <Hixie_> | how do you mean? |
| 17:21 | <TabAtkins> | When you're invoking the sizing algorithm, say that the default image size is the dimensions of the <img>. |
| 17:26 | <Hixie_> | the img's dimensions are what i'm trying to figure out |
| 17:26 | <Hixie_> | i don't follow |
| 17:26 | <Hixie_> | also i don't think i call the algorithm, i think that's css layout that does that |
| 17:38 | <annevk> | TabAtkins: it seems all HTML can give here is the height and width attributes, which already map to CSS |
| 17:38 | <annevk> | And I guess if HTML does the image decoder negotiation it could give information from that too... |
| 17:47 | <TabAtkins> | annevk: Ah, right, yeah. |
| 17:51 | <miketaylr> | back |
| 18:10 | <TabAtkins> | Hixie_: Ah, if you're trying to size the <img> itself, then CSS2.1 describes how to do it. Alan just invoked that algorithm yesterday, let me go look up the incantation. |
| 18:18 | <zcorpan_> | hmm, the trackpad on my mac just went crazy. it's super sensitive and inverted in both directions |
| 18:24 | <gsnedders> | Hmm, so warranty replacement for my rucksack will only ship to US. Is there going to be any sane way to get that here without it costing more than the bag is worth… |
| 18:24 | <gsnedders> | Probably best bet is just to take a slightly large suitcase when I next go and take it that way… |
| 18:39 | <zcorpan_> | ah, trackpad back to normal. phew. |
| 19:00 | <zcorpan_> | MikeSmith: does http://critic.hoppipolla.co.uk/r/351 support `static interface ...` ? |
| 19:01 | <jgraham> | zcorpan_: OK, the jgraham/python_review_2 branch now has all the track tests up to 010.html pass in opera |
| 19:02 | <zcorpan_> | jgraham: great |
| 19:14 | <zcorpan_> | MikeSmith: hmm, nevermind, seems like there's no static interface thing. confused it with something else |
| 19:15 | <zcorpan_> | [Unforgeable] |
| 19:16 | <Ms2ger> | jgraham, I'll try to look at the review a bit tomorrow |
| 19:19 | <jgraham> | Ms2ger: Awesome, thanks |
| 19:22 | <astearns> | TabAtkins: is this the incantation you're looking for? http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width |
| 19:29 | <Ms2ger> | 2.1? Probably not |
| 19:31 | <zcorpan_> | jgraham: when i submit changes in critic, is there a way to make it go back to the review instead of going to the default page? |
| 19:32 | <zcorpan_> | 0.02 % done, that's encouraging :-) |
| 19:58 | <TabAtkins> | astearns: Yeah, that's it. |
| 20:08 | <zcorpan> | jgraham: was there some change other than https://github.com/w3c/web-platform-tests/commit/b1486aa82b4174df577bb00f1796fe4a5bc5bffc ? |
| 20:09 | <zcorpan> | (and the comma fixup) |
| 20:10 | <jgraham> | zcorpan: I thpught it did go back to the review, but I might have imagined that |
| 20:10 | <jgraham> | In any case the answer is generically "ask jl" |
| 20:11 | <jgraham> | zcorpan: Those and replaicing cors-tester.php with cors-tester.py (and all the substitutions that implies) |
| 20:12 | <zcorpan> | jgraham: yeah i meant between the state of cors-tester.py last i looked at it and the latest fixup commit |
| 20:16 | <jgraham> | Right, those are the only changes in that case |
| 20:17 | <zcorpan> | ok |
| 20:41 | <Hixie_> | TabAtkins: that ends with "then the used value of 'width' is undefined in CSS 2.1." for the case i care about :-P |
| 20:43 | <Hixie_> | TabAtkins: isn't this what css-images is defining? |
| 20:44 | <zcorpan> | jgraham: looks like i get the same results as on t now. excellent! |
| 20:50 | <Hixie_> | bugzilla needs a severity field value that's like "enhancement" but means "removal of feature" |
| 20:51 | <TabAtkins> | Hixie_: Yaaaayyy |
| 20:51 | <jgraham> | zcorpan: Oh! |
| 20:51 | <TabAtkins> | Hixie_: Man, I dunno. fantasai convinced me that the 2.1 handling of replaced elements wasn't actually quite compatible with the Image Sizing Algorithm, and making them compatible wouldn't be worth it. |
| 20:52 | <TabAtkins> | But I've paged that argument out of my head for a while. |
| 20:53 | <Hixie_> | TabAtkins: someone filed a bug on me saying this case wasn't well-defined... should I reasssign it to you for now? (I'm happy to have it assigned to me, I just don't know what I should say to fix it.) |
| 20:54 | <jgraham> | Hixie_: BTW, how paged in do you have the session history stuff? It is being designed for servo at the moment and bholley was threatening to grill you on it |
| 20:54 | <jgraham> | So take this as advance warning ;) |
| 20:54 | <Hixie_> | hehe |
| 20:55 | <Hixie_> | not particularly paged in, but it's not as hard to page in as the parser :-) |
| 20:55 | <jgraham> | I find it much harder :) |
| 20:59 | <TabAtkins> | Yeah, assign it to me |
| 21:00 | <Hixie_> | k |
| 21:08 | <Hixie_> | TabAtkins: done - https://www.w3.org/Bugs/Public/show_bug.cgi?id=23581 |
| 21:14 | <zcorpan> | jgraham: no support for wss: ? |
| 21:35 | <zcorpan> | wow https://www.w3.org/Bugs/Public/show_bug.cgi?id=23587 |
| 21:36 | <zcorpan> | it took a few years, but the planets did line up |
| 21:38 | <jgraham> | zcorpan: *s is hard because certificates |
| 21:39 | <zcorpan> | jgraham: but https works? |
| 21:39 | <jgraham> | no |
| 21:39 | <zcorpan> | oh |
| 21:39 | <zcorpan> | ok |
| 21:40 | <jgraham> | For Mozilla infrastructure we will probably install a CA fir the duration of the tests (that's how Mochitest works) |
| 21:40 | <jgraham> | Opera/Google/Microsoft/Apple could do something similar on their test infrastructure |
| 21:40 | <jgraham> | For people running the tests at home I'm not sure what we will do |
| 21:41 | <Hixie_> | abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 |
| 21:42 | <zcorpan> | jgraham: we can put in job openings |
| 21:43 | <Hixie_> | zcorpan: got any suggestions for that <script> bug? |
| 21:43 | <jgraham> | Well "at home" in this case really includes any situation where you don't run a browser-specific script to launch the tests |
| 21:46 | <zcorpan> | Hixie_: i think the recommendation should be to escape the < in <!-- and <script |
| 21:46 | <Hixie_> | yeah that was my conclusion too |
| 21:46 | <Hixie_> | or the ! and the s |
| 21:46 | <Hixie_> | as in <\!-- and <\script |
| 21:46 | <zcorpan> | right |
| 21:47 | <zcorpan> | and </script of course |
| 21:47 | <Hixie_> | yeah, always <\/script |
| 21:47 | <Hixie_> | oh course the _real_ answer is "don't do string substitution into your script" |
| 21:48 | <Hixie_> | when will people learn |
| 21:51 | <zcorpan> | Hixie_: also say that authors can ignore the script content model restrictions and instead avoid wrapping <!-- --> and properly escaping |
| 21:52 | <zcorpan> | since the restrictions are impossible to understand |
| 21:53 | <Hixie_> | oh that's an idea. Just have in that section some text that says that the easiest way to avoid this is to just escape all <!-- and <script> bits? |
| 21:54 | <zcorpan> | yeah |
| 21:55 | <zcorpan> | wonder if it's a good idea to make validators complain about <!-- always |
| 21:56 | <zcorpan> | it's pretty common, but OTOH it's a very legacy practice, and it's not without issues |
| 21:56 | <Hixie_> | i'd be fine with doing so, but hsivonen and MikeSmith are reluctant to warn on "harmless" stuff |
| 21:56 | <Hixie_> | which i can understand |
| 21:56 | <Hixie_> | since it makes the validator less likely to be used, arguably |
| 21:58 | <zcorpan> | yeah |
| 21:58 | <zcorpan> | i guess it's harmless until you enter double escaped state |
| 22:00 | <zcorpan> | hsivonen: MikeSmith: WDYT? |
| 22:00 | zcorpan | -> sleep |
| 22:18 | <Hixie_> | sweet kittens, i got a bunch of parse errors trying to write the parser section on avoiding parser errors. |
| 22:29 | <annevk-cloud> | oh man that security bug |
| 22:30 | <annevk-cloud> | one day |
| 22:30 | <Hixie_> | you think that's bad |
| 22:30 | <Hixie_> | try this one: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366 |