| 00:36 | <rniwa> | TabAtkins, Hixie: yt? |
| 05:08 | <mustang89> | holy crap i didn't even know mirc was around still looks like it did in 99 |
| 05:08 | <mustang89> | almost |
| 06:47 | <zcorpan> | should the whitespace after the image in the second row be collapsed per spec? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1417 |
| 06:48 | <Hixie> | white-space:normal? |
| 06:48 | <Hixie> | if so, yes, white space at the end of the line is collapsed in 'normal' |
| 06:49 | <Hixie> | see css2.1 bottom of section 10, iirc |
| 06:51 | <zcorpan> | i don't see anything about this in section 10 |
| 06:52 | <Bhanu> | what is irc? |
| 06:52 | <Bhanu> | I saw it first time |
| 06:52 | <Bhanu> | can anyone tell me |
| 06:52 | <Bhanu> | what is irc? |
| 06:54 | <zcorpan> | Hixie: "Each tab (U+0009), carriage return (U+000D), or space (U+0020) character surrounding a linefeed (U+000A) character is removed if 'white-space' is set to 'normal', 'nowrap', or 'pre-line'." (in 16.6.1)? |
| 06:55 | <zcorpan> | Bhanu: https://en.wikipedia.org/wiki/IRC |
| 06:56 | <zcorpan> | oh, no, it's "If a space (U+0020) at the end of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is also removed." |
| 06:59 | <zcorpan> | hmm. there was a site relying on it *not* being collapsed (and firefox doesn't collapse it). at least in almost standards mode/quirks mode. |
| 07:00 | <zcorpan> | wonder if we should try to follow webkit/spec and break the site or specify not to collapse it in almost/quirks |
| 07:03 | <Bhanu> | thanks zcorpan |
| 07:05 | <zcorpan> | np Bhanu, and welcome |
| 07:05 | <zcorpan> | what brought you here? |
| 07:30 | <annevk> | was it some kind of special day yesterday? no new email |
| 07:43 | <Bhanu> | sorry to delay... zcorpan. I brought to here by reading a book named "HTML5 for web designer" |
| 08:24 | <zcorpan> | so about the global scope pollution thing, would it be a reasonable compat compromize to limit it to quirks mode *and almost standards mode* ? |
| 08:26 | <Ms2ger> | Currently the table thing is the only limited quirk, right? |
| 08:27 | <zcorpan> | the line height calculation quirk, yeah |
| 08:28 | <annevk> | still no answer from anyone http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0153.html |
| 08:28 | <annevk> | meh |
| 08:29 | <hsivonen> | zcorpan: seems like a slippery slope to let Almost Standards and Standards diverge some more |
| 08:29 | <annevk> | same: http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0265.html |
| 08:30 | <annevk> | guess I'll just file bugs on those too |
| 08:30 | <zcorpan> | hsivonen: maybe. but if the choice is that and having global scope pollution in standards mode... |
| 08:30 | <Ms2ger> | Meh, I think EnforceRange is silly |
| 08:30 | <annevk> | you can say so in the bug |
| 08:31 | <zcorpan> | annevk: i think we should allow manipulation of xmlns attributes and let namespace algorithms do what they do (i.e. don't try to prevent people to shoot themselves in the foot) |
| 08:32 | <annevk> | do what they do? |
| 08:32 | <annevk> | not sure they look at xmlns attributes now |
| 08:33 | <zcorpan> | i thought they do, but i never researched the namespace algorithms properly |
| 08:34 | <zcorpan> | lookupPrefix i think looks at xmlns attributes |
| 08:34 | <zcorpan> | in some impls at least |
| 08:35 | <zcorpan> | per spec as well it seems |
| 08:37 | <zcorpan> | annevk: note that the html parser can produce namespace declarations that are wrong, so we're not making sure the tree doesn't have wrong namespace declarations by restricting setAttribute* |
| 08:37 | <zcorpan> | e.g. <svg xmlns="foo"> |
| 08:37 | <annevk> | Ms2ger: fyi, just filing these bugs so I don't have to keep track of the email anymore, I don't actually believe we should fix all of them |
| 08:38 | <Ms2ger> | Yeah |
| 08:38 | <annevk> | inbox <250 teehee |
| 08:38 | <Ms2ger> | 90 |
| 08:39 | <annevk> | zcorpan: the spec does not look at the namespace of xmlns? |
| 08:39 | <annevk> | hmm nope |
| 08:40 | <annevk> | bug? |
| 08:42 | <zcorpan> | i think we should do the minimal set of checks that work when the attributes are correct |
| 08:42 | <zcorpan> | and let the result be bogus when they are not correct |
| 08:43 | <zcorpan> | just like we don't care about innerHTML making sense when modifying the tree in a way that text/html cannot represent |
| 08:46 | <annevk> | i guess that's fair |
| 08:47 | <annevk> | so, does it match implementations? :) |
| 08:48 | <zcorpan> | last time i checked impls aren't anal about keeping namespace declarations correct |
| 08:48 | <zcorpan> | but with little interop |
| 08:48 | <annevk> | serializing will also be a bitch :/ |
| 08:50 | <zcorpan> | serializing should rewrite namespace prefixes to match the actual namespaces, iirc. but yeah, that's a bitch |
| 08:50 | <zcorpan> | and browsers don't actually do that last i checked :-) |
| 08:51 | <annevk> | I think Gecko might |
| 08:51 | <annevk> | but that still leaves namespaceless xmlns |
| 08:51 | <annevk> | meh |
| 08:51 | <Ms2ger> | zcorpan, a spec for that would be appreciated :) |
| 08:52 | <zcorpan> | Ms2ger: i'll try to finish this quirk thing first :-P |
| 08:53 | <Ms2ger> | I guess that's fair |
| 09:42 | <jgraham> | zcorpan: Is there any evidence that almost-standards mode covers a significant fraction of the sites that depend on the quirk? |
| 09:43 | <jgraham> | (the global scope polluter, I mean) |
| 09:54 | <zcorpan> | jgraham: no. though i haven't seen any evidence about standards mode usage, either, apart from the demo |
| 09:55 | <zcorpan> | all i know so far is adrian saying "i think this will break many sites in IE" |
| 10:25 | <zcorpan> | matjas: why do you have a mapping for zero width space? |
| 10:26 | <matjas> | zcorpan: surprisingly, i need it quite frequently. mostly when tweeting e.g. @font-face without turning it into a mention |
| 10:28 | <matjas> | zcorpan: it also makes it a bit easier to test js-escapes and css-escapes for white space edge cases (although i still need https://github.com/mathiasbynens/dotfiles/blob/master/.functions#L53-57 for proper testing) |
| 10:28 | <zcorpan> | k |
| 11:27 | <zcorpan> | hmm. http://simon.html5.org/specs/quirks-mode#the-blocks-ignore-line-height-quirk applies in almost standards mode too |
| 12:26 | <smaug____> | why do I have some many copies of DOM4 open.. |
| 12:26 | <smaug____> | AppTab helps |
| 12:29 | <Ms2ger> | Because it's such a nice spec? ;) |
| 12:40 | <zcorpan> | foolip: <!-- As of |
| 12:40 | <zcorpan> | 2005-12, studies showed that around 0.2% of pages used the |
| 12:40 | <zcorpan> | <image> element. --> |
| 12:40 | <zcorpan> | foolip: changing <image> now seems disruptive even if it's less than 0.2% today |
| 12:41 | <foolip> | zcorpan, yeah, I guess :( |
| 12:42 | <zcorpan> | foolip: having multiple <img>s seems to have the wrong behavior in legacy browsers |
| 12:42 | <foolip> | zcorpan, because they are fetched even or display:none? (are they?) |
| 12:42 | <zcorpan> | they are, yeah |
| 12:42 | <foolip> | again, :( |
| 12:43 | <zcorpan> | and this feature could be designed to work without needing CSS for legacy browsers |
| 12:44 | <foolip> | without even CSS? that seems excessively backwards compatible |
| 12:44 | <zcorpan> | the proposed markup doesn't need css to show a single image in legacy browsers |
| 12:47 | <foolip> | Yes, but I'm not a fan of using <source> |
| 12:47 | <zcorpan> | that's reasonable |
| 12:47 | <foolip> | Maybe I wouldn't care if I didn't know about the resource selection algorithm |
| 12:47 | <zcorpan> | call it something else :-) |
| 12:57 | <zcorpan> | seems to me it should be more like |
| 12:57 | <zcorpan> | <picture> |
| 12:57 | <zcorpan> | <source src=mobile.jog resolution=20dpi> |
| 12:57 | <zcorpan> | <source src=hires.jpg resolution=200dpi> |
| 12:57 | <zcorpan> | <img src=lowres.jpg resolution=96dpi alt="fallback text"> |
| 12:57 | <zcorpan> | </picture> |
| 12:58 | <zcorpan> | where the browser downloads the image that is "good enough" for the current zoom level, and never downloads a lower resolution image than the ones it already has |
| 12:59 | <foolip> | um, so <img> takes part in the resource selection and is not just a fallback? |
| 12:59 | <zcorpan> | supporting full MQ here probably leads to authors using it incorrectly, like the spec currently has it wrong (it would download the mobile version when you zoom in) |
| 12:59 | <zcorpan> | yeah, that seems nice for DRY |
| 13:00 | <zcorpan> | and making sure legacy browsers don't get left in the cold |
| 13:00 | <zcorpan> | maybe the <img> has an implied resolution=96dpi and that can't be changed |
| 13:00 | <foolip> | yeah, but it'll just look weird in 5 years when legacy browsers are irrelevant |
| 13:00 | foolip | -> fika |
| 13:00 | <zcorpan> | so? |
| 13:01 | <zcorpan> | in five years bandwidth won't be a problem so you can just use <img> again :-) |
| 13:01 | <zcorpan> | also, lots of stuff in html looks weird because they were designed to be backwards compatible |
| 13:24 | <zcorpan> | media="" on <source> might well be a misfeature that we should drop |
| 13:27 | <zcorpan> | ok i commented on the picture spec |
| 13:51 | <zcorpan> | Hixie: btw, seems i was wrong about coordinate vs coordinates |
| 13:52 | <jgraham> | zcorpan: One might wonder if your <img adaptive> proposal couldn't be spelt <img> |
| 13:52 | <jgraham> | I guess that will break something for some reason |
| 13:53 | <zcorpan> | jgraham: i suspect making Range requests for all <img>s would break sites |
| 13:53 | <zcorpan> | but i don't have data on that |
| 14:05 | <zcorpan> | or pages might have progressive JPEGs but expect them to be fully downloaded so they can paint them on a canvas or so |
| 14:07 | <zcorpan> | also, an attribute can be feature-checked so you could choose to use a 96dpi image for legacy browsers and a 200dpi image for supporting browsers |
| 14:09 | <zcorpan> | which maybe could be spelled as <img src=96dpi.jpg adaptive=200dpi.jpg> (empty string for adaptive would use src instead) |
| 14:15 | <jgraham> | Interesting idea |
| 14:15 | <jgraham> | The one I like most so far, I think |
| 14:19 | <zcorpan> | ok updated my comment with that |
| 15:24 | <Wilto> | My ears were ringing. Hi, guys! |
| 15:26 | <Wilto> | jgraham: Unfortunately, we were informed pretty early on by a number of vendors that they weren’t willing to bypass image prefetching based on the existence of an attribute. |
| 15:27 | <Wilto> | jgraham: <img src="…" adaptive="…"> would still leave us downloading the original src first, then swapping it for the second src. |
| 15:28 | <Wilto> | The Chrome folks did all but post “LOL” somewhere. Hence our working around <img> altogether—for that reason, and to avoid introducing potential issues in older browsers (granted, the `adaptive` attr wouldn’t, but in general). |
| 15:29 | <Wilto> | We did a lot of that early brainstorming here: https://etherpad.mozilla.org/responsive-assets |
| 15:29 | <Wilto> | And a lot of this ground has been covered in the CG, even though it’s a bit distributed across posts and comments. We did our best to keep all conversation public and easily-parsed. |
| 15:33 | <Wilto> | It's been a disjointed "process," but there isn’t a hell of a lot of precedent for this "from Community Group to standard" chain of events. If theres anything I can do to help out with the history, please don’t hesitate to pester me. I turned into the spokeperson somewhere along the line. |
| 15:35 | <Wilto> | And I want to stress that I'm after _a_ solution, not "my" solution. I’m not married to <picture>, but all roads seem to lead that way the longer the discussion goes on. Completely open mind, here. |
| 15:36 | <Wilto> | (End rant.) |
| 15:58 | <jgraham> | 10:27 < Wilto> jgraham: <img src="…" adaptive="…"> would still leave us downloading the original src first |
| 15:58 | <jgraham> | why? |
| 15:59 | <jgraham> | Wilto: ^ |
| 15:59 | <jgraham> | AIUI in zcorpan's proposal you download exactly one image, ever |
| 16:00 | <jgraham> | It's just that you use http range requests to only download enough data for the resolution you have |
| 16:01 | <jgraham> | ofc it doesn't solve the use case of "display entirely different images based on screen size" |
| 17:33 | <volkmar> | is there an api out there with something like success()/succeded()/postSuccess() methods? I'm trying to name a method with a bit of consistency... |
| 17:38 | <AryehGregor> | volkmar, IDB comes to mind. |
| 17:38 | <AryehGregor> | Resource loads tend to use onload/onerror. |
| 17:39 | <volkmar> | actually, I was looking for something doing the call, not handling the event |
| 17:40 | <volkmar> | but I guess I will just go with something and hope someone will tell me if I'm wrong |
| 20:14 | <Ms2ger> | Oh hey, it's jgraham in my bugzilla |
| 21:10 | <jgraham> | Ms2ger: Be afraid, very afraid |
| 21:11 | <Ms2ger> | So, when are you guys implementing event ctors? |
| 21:15 | <jgraham> | Ms2ger: Wrong tense |
| 21:15 | <Ms2ger> | Oh? |
| 21:16 | <jgraham> | Unless you mean more than "new Event('foo')" |
| 21:16 | <Ms2ger> | Yep |
| 21:16 | <Ms2ger> | StorageEvent |
| 21:18 | <jgraham> | Ah. Probably when jl (or sof or bratell or a number of other people) has five minutes and the inclination then. |
| 23:15 | <Hixie> | hmm, i suppose if path is null and we're using the current default path i should throw if a transform is provided to addHitRegion... |
| 23:18 | <Hixie> | any dom core editors around? |
| 23:18 | <Hixie> | actually i guess MouseEvent isn't in DOM Core |
| 23:18 | <Hixie> | what spec defines the MouseEvent constructor these days? |
| 23:23 | <paul_irish> | http://html5labs.com/dom4events/#constructors-mouseevent maybe? |
| 23:23 | <Hixie> | ah, cool, thanks |
| 23:24 | <jwalden> | anyone have a recent copy of IE10 to test something for me? I need to know what |Object.create(new DataView(new ArrayBuffer(8))).setUint8(2, 5)| in http://www.squarefree.com/shell/shell.html produces there |
| 23:24 | <Hixie> | heycam: can i do "partial dictionary Foo { foo myNewMember }" ? |
| 23:25 | <heycam> | you cannot, sorry |
| 23:25 | <heycam> | did you ask that recently, or was that someone else? |
| 23:25 | <heycam> | one problem with allowing it is that we need to have a defined order for dictionary members, so that the properties can be got in a fixed order |
| 23:26 | <heycam> | with partials, you don't have any ordering between the different fragments |
| 23:26 | <jwalden> | specifying property enumeration order? :-( |
| 23:26 | <Hixie> | heycam: hmm |
| 23:27 | <heycam> | jwalden, nah, just order of fetching properties from an object that's being used as a dictionary |
| 23:27 | <jwalden> | heycam: oh, you mean like for Object.defineProperty(..., ..., { enumerable: true, configurable: true }) what order enumerable/configurable are gotten? |
| 23:27 | <jwalden> | that ordering I am happy to have spec'd :-) |
| 23:27 | <heycam> | jwalden, yeah |
| 23:27 | <jwalden> | good, good |
| 23:28 | <Hixie> | heycam: i think it's going to become almost necessary given events |
| 23:28 | <heycam> | hmm really? |
| 23:28 | <Hixie> | heycam: and their constructors |
| 23:28 | <heycam> | why's that? |
| 23:28 | <Hixie> | brb |
| 23:29 | <jwalden> | event constructors taking dictionaries means you have to say what order the properties are retrieved, so that getters can have effects in the proper order and all, I think |
| 23:30 | <jwalden> | and I understand the event ctors to go crazy with dictionaries, because passing all of 'em as arguments is cracktastic |
| 23:30 | <heycam> | yeah, it's a much nicer pattern to use |
| 23:30 | <heycam> | still not sure why partial dictionaries are required though |
| 23:32 | <Hixie> | heycam: sorry, back |
| 23:32 | <Hixie> | heycam: say i want to add a member to MouseEvent |
| 23:32 | <heycam> | and you don't want to ask annevk to do it? :) |
| 23:32 | <Hixie> | heycam: how do i do that, assuming i'm not a mainstream spec (i.e. who can convince microsoft ot add it) |
| 23:33 | <heycam> | fork the spec? :) |
| 23:34 | <Hixie> | that seems like a bit of a heavyweight for one extra member :-P |
| 23:34 | <heycam> | how are you going to use this extra member? |
| 23:34 | <heycam> | I mean, what function is going to look at it? |
| 23:35 | <Hixie> | i would want to add a member to the dictionary so that it can be passed to the constructor so that it can set a new member i would also add to the MouseEvent interface |
| 23:35 | <Hixie> | same way as all the other members on event init dictionaries |
| 23:35 | <heycam> | I see, so you wouldn't need to redefine the constructor, because it's already written in terms of whatever members exist on the dictionary |
| 23:36 | <Hixie> | right |
| 23:37 | <heycam> | if we have two partial dictionary definitions, how do we decide how they are ordered? |
| 23:37 | <heycam> | currently dictionary members are defined to be got in the order they appear in the IDL |
| 23:37 | <heycam> | with ones on ancestors got before ones on descendants |
| 23:37 | <Hixie> | change the definition to be alphabetical :-) |
| 23:38 | <heycam> | yeah that's one way! :) |
| 23:39 | <paul_irish> | jwalden: browserstack has ie10pp2 to play with |
| 23:40 | <jwalden> | paul_irish: ooh, it does? good to know for next time (I got an answer in #developers a second ago) |
| 23:40 | <jwalden> | although, I think pp2 is before they went to only-available-with-a-new-OS system, and I actually have that preview installed |
| 23:41 | <paul_irish> | correctomundo |
| 23:41 | jwalden | is not interested in blowing away his working OS solely to test IE10 :-) |
| 23:41 | <heycam> | Hixie, I guess we could even be consistent with current ordering (in case there is a reliance on order already, which I guess is unlikely) by doing the alphabetical thing only for the partial-included dictionary members |
| 23:42 | <Hixie> | heycam: we could do that, yeah. though generally i'm a bit suspicious of making partial dicts or interfaces having detectable results since the idea is that 'partial' is just an editorial aid |
| 23:43 | <heycam> | Hixie, yeah I guess so |
| 23:44 | <heycam> | the alphabetical order just seems a bit funny to me |
| 23:45 | <WeirdAl> | [partial] Dictionary |
| 23:45 | <Hixie> | could order it by the sum of the unicode codepoints of the characters in the name, it's even more silly :-P |
| 23:45 | <WeirdAl> | extra attributes ftw :p |
| 23:45 | <heycam> | heh |
| 23:45 | <jwalden> | normatively order it depending on the phase of the moon |
| 23:46 | <heycam> | mint a uuid for each partial dictionary, order based on that |
| 23:47 | <Hixie> | that goes back to the editorial details having normative effects |