| 04:28 | <kodkod> | irc is so oldschool |
| 04:28 | <zewt> | yeah, it's way too functional for today's internet |
| 04:29 | <kodkod> | heh there were times when i use to be an ircop on some servers :) |
| 05:15 | <zcorpan> | Hixie: turns out "soon" didn't match reality eh? i really don't like this. can fixed bugs be marked in some other way that is possible to search/filter for? |
| 05:42 | <zcorpan> | role attribute? |
| 05:42 | zcorpan | blinks |
| 05:43 | <zcorpan> | i thought the PFWG had taken the attribute and defined it completely in the ARIA spec *years* ago, since the role spec was useless |
| 08:05 | <annevk> | zcorpan: it's that time when everything old is new again |
| 08:06 | <annevk> | see also: HTML WG |
| 08:21 | <annevk> | yay zewt for following up on the File API mess |
| 08:22 | <annevk> | zewt: maybe it can be some kind of post-URL-parser steps that do this |
| 08:23 | <annevk> | zewt: that way not all specs have to special case Blob URLs |
| 08:43 | <sedovsek> | Anyone knows whether Page Visibility works on iOS/Androids (hint: it does not :/)? Are there any workarounds? |
| 08:43 | <sedovsek> | http://www.w3.org/TR/2011/WD-page-visibility-20110602/ |
| 08:53 | <annevk> | okay, I'm no longer stalking people in Mozilla or WebKit Bugzilla |
| 08:53 | <annevk> | this means that if you cc me there's a somewhat bigger chance I'll take a look |
| 08:58 | <Ms2ger> | Did I spam you too much? :) |
| 09:23 | <annevk> | I had 80k unread Gecko threads and 30k unread WebKit |
| 09:24 | <annevk> | time to give up the experiment :) |
| 09:24 | <annevk> | now marking everything as read and see how it goes |
| 09:28 | <annevk> | When is Gmail going to remove the "Invite a friend" box? |
| 09:38 | <sedovsek> | @annevk : ) |
| 09:38 | <sedovsek> | I've seen you're giving a talk at the fronteers conf. |
| 09:39 | <sedovsek> | Looking forward already. |
| 09:40 | <annevk> | ah yeah, Fronteers will be fun :) |
| 09:41 | <sedovsek> | Yea… go to Amsterdam they said. |
| 09:41 | <sedovsek> | It will be fun they said. |
| 09:55 | <annevk> | no worries, our http://en.wikipedia.org/wiki/Levee have been safe since the fifties |
| 09:56 | <annevk> | (too many words for one thing in English) |
| 10:02 | <SimonSapin> | funny how English uses a French word where French has a different word (digue) |
| 10:02 | <annevk> | English has that too |
| 10:02 | <annevk> | dike/dyke |
| 10:02 | <annevk> | dijk in Dutch |
| 10:11 | <Lachy> | be careful of using the word dike in English. It has an unfortunate slang meaning. |
| 10:13 | <beverloo> | Don't you mean dyke? |
| 10:34 | <hsivonen> | almost every English word seems to have slang meanings that make you uneasy about using the word if you look it up on urbandictionary :-( |
| 10:34 | <hsivonen> | (not to suggest disagreement with Lachy's warning) |
| 10:37 | <annevk> | http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx cross-platform :/ |
| 10:38 | <hsivonen> | looks like they are bold enough to break the Desktop/Phone/Tablet taxonomy and instead go with a touch / no touch |
| 10:39 | <hsivonen> | unless, of course, they later ship IE10 for phones with yet another UA string anyway |
| 10:39 | <hsivonen> | in which case they could have said Tablet instead of touch for compat with Firefox and Opera |
| 10:39 | <annevk> | it doesn't really seem compatible with Microsoft's platform vision of being able to interact with everything in whatever way you want either |
| 10:40 | <annevk> | if the UA advertises touch and I have a keyboard hooked up there's a fair chance I'm going to be in trouble, which seems kind of contrary to recent Microsoft vision announcements |
| 10:40 | <hsivonen> | fwiw, I expect the strategy of putting touch screens on desktops to flop for ergonomic and aesthetic reasons |
| 10:40 | <Ms2ger> | annevk, maybe you should get yourself hired by MS :) |
| 10:41 | <annevk> | hsivonen: well yeah, me too |
| 10:41 | <annevk> | hsivonen: just pointing out some inconsistency here :) |
| 10:42 | <hsivonen> | annevk: well, Mozilla's platform engineers supposedly prefer capability sniffing, but we still cater to non-top-tier Web authors who want to assume a Desktop/Tablet/Phone taxonomy and UA sniff for it |
| 10:43 | <annevk> | seems bad for fingerprinting, but I guess it's exposed in other ways already |
| 10:43 | <annevk> | (though it does make it easier) |
| 10:43 | <hsivonen> | I should note that Opera's local-Presto products do it, too |
| 10:44 | <hsivonen> | In which light I find it odd that Opera Mini doesn't expose tabletness in the UA string |
| 10:44 | <hsivonen> | even though Mini spews out fingerprinting surface without any concern by exposing the exact device model |
| 10:44 | <annevk> | I have attempted to fix various bits of our UA string, but somehow missed out when we started screwing it up again :/ |
| 10:46 | <hsivonen> | I was trying to advocate that Mozilla do it exactly like Opera (with "Mobi" and "Tablet"), but we ended up doing it with "Mobile" and "Tablet" |
| 10:46 | <hsivonen> | which still allows clueful people handle Firefox and Opera form-factor sniffing using the same code |
| 10:47 | <hsivonen> | not sure how much of a lost cause it is to design UA strings to be nicely sniffable by clueful sniffers |
| 10:48 | <annevk> | for a moment there I was hopeful the IE blog used <mark> |
| 10:48 | <annevk> | turns out it's <span style="background-color: yellow;">Touch</span> |
| 10:49 | <hsivonen> | <mark> would have made it so much more Semantic |
| 10:49 | <annevk> | :) |
| 10:52 | <annevk> | the web needs a new Mark Pilgrim for some level-headed commentary |
| 10:52 | <annevk> | there's @mattur but he's limited to 140 characters |
| 10:53 | <niloy> | the IE blog is a sad piece of software, no rounded corners, no gradients, looks like 2006 |
| 10:54 | <hsivonen> | the AC should be outraged that the W3C's resources have gone into publishing an XHTML2 module, but chances are no one even gets a slap on the wrist for it |
| 10:55 | <annevk> | W3C doesn't know what it's doing; film at eleven |
| 10:58 | <hsivonen> | it'll be interesting to see what will be put forward as the two interoperable implementations |
| 10:59 | <hsivonen> | my guess is: two XML editors that don't barf on a DTD that declares an attribute called role |
| 10:59 | <Ms2ger> | My guess is that they won't bother and nobody will complain |
| 11:00 | <hsivonen> | Björn might |
| 11:00 | hsivonen | looks forward to another spiderman episode |
| 11:20 | <hsivonen> | hmm. looks like the email where I proposed Mozilla stop prefixing APIs got Warnocked |
| 11:21 | <hsivonen> | well, on the positive side, while I was away, various CSS things were unprefixed in Gecko |
| 11:22 | <smaug____> | it is not clear to me when to prefix an API an when not |
| 11:23 | <smaug____> | btw, IDB got unprefix |
| 11:23 | <smaug____> | ed |
| 11:23 | <hsivonen> | I think we should not prefix |
| 11:23 | <hsivonen> | yay for IDB unprefixing |
| 11:23 | <smaug____> | hsivonen: even when implementing highly unstable APIs? |
| 11:23 | <hsivonen> | and I think we shouldn't ship to release channel stuff that we don't expect to be able to live with forever |
| 11:23 | <hsivonen> | smaug____: I think we shouldn't ship those |
| 11:24 | <smaug____> | that is possibly true |
| 11:24 | <hsivonen> | smaug____: or if we ship, we shouldn't pretend they are unstable |
| 11:24 | <hsivonen> | smaug____: I'd expect people who write apps for the first release of Firefox OS to be unhappy if we treated their apps as having been written on top of unstable APIs |
| 11:24 | <smaug____> | but the problem is that we get even less feedback from web devs, if APIs aren't in a release |
| 11:25 | <smaug____> | getting feedback from web devs is always difficult |
| 11:25 | <hsivonen> | smaug____: we get so little feedback even now that I think the delta isn't worth the trouble prefixing causes |
| 11:25 | <smaug____> | could be |
| 11:26 | <hsivonen> | I guess I should go write a couple of patches now |
| 11:28 | <hsivonen> | speaking of feedback from Web devs, it would be interesting to count the bugzilla items we've got from various Web devs who position themselves as standards advocates |
| 11:39 | hsivonen | finds out about http://annevankesteren.nl/2012/07/leaving-opera whoa |
| 11:39 | <Ms2ger> | Did you hear about chaals? :) |
| 11:42 | <hsivonen> | Ms2ger: I heard a claim that he left Opera |
| 11:43 | <hsivonen> | Ms2ger: I haven't heard if it was true or where he went yet |
| 11:43 | <Ms2ger> | It's true, and Yandex |
| 11:45 | Ms2ger | is fascinated by the addendum at http://annevankesteren.nl/2012/07/interview being older than the post otself |
| 11:45 | <Ms2ger> | *itself |
| 12:11 | <karlcow> | hsivonen: Chaals left Opera for Yandex. |
| 12:14 | <hsivonen> | interesting destination |
| 12:19 | <karlcow> | Ms2ger: the fascinating thing is that the home page says now, and the article page says July 13th |
| 12:20 | <karlcow> | hsivonen: interesting in which way? |
| 12:21 | <hsivonen> | karlcow: in the way that Yandex is not known as a browser vendor and (AFAICT) not as a particularly active participant at the W3C |
| 12:23 | <karlcow> | hsivonen: there is a life (and businesses) outside of browser vendors ;). For Yandex and W3C, I guess they have indirect influence by their huge market share in Russia. |
| 12:26 | <karlcow> | indeed participation is subpar for now, at least for people using yandex emails |
| 12:26 | <karlcow> | http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=from&hdr-1-query=yandex-team.ru&index-grp=Public_FULL&index-type=g&type-index= |
| 12:27 | <karlcow> | ah there is also |
| 12:27 | <karlcow> | http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=from&hdr-1-query=yandex.ru&index-grp=Public_FULL&index-type=g&type-index= |
| 12:28 | <karlcow> | maybe generic emails yandex.ru |
| 12:29 | <zcorpan> | chaals⊙oc Results : 2117 |
| 12:32 | <karlcow> | Sidar → RMIT → W3C → Opera → Yandex |
| 12:59 | <zcorpan> | TabAtkins_: does http://lists.w3.org/Archives/Public/www-style/2012Apr/0321.html "a00000" still apply? afaict it's an identifier and would be converted. please file a bug if the spec's wrong |
| 13:00 | zcorpan | goes offline now for a few weeks |
| 13:11 | <kodkod> | hello |
| 13:16 | <hsivonen> | sigh. Source Maps have a format version identifier |
| 13:27 | <hsivonen> | Do we have a canned reference for explaining why versioning is an anti-pattern for Web formats? |
| 13:46 | <kennyluck> | Well Marat Tanalin is pretty active in every mailing list. |
| 13:48 | <Ms2ger> | Is that Marat Tanalin | Advertising? |
| 13:48 | <kennyluck> | huh |
| 13:49 | <hsivonen> | kennyluck: does he/she work for Yandex or just use their webmail? |
| 13:49 | <hsivonen> | as in: people with @yahoo.com addresses don't necessarily work for Y! |
| 13:49 | <hsivonen> | either |
| 13:49 | <kennyluck> | hsivonen, good question. I don't know. |
| 13:50 | hsivonen | wonders how long until )]} prepended to JSON becomes an official part of JSON |
| 13:56 | <SimonSapin> | hsivonen: prepended how? |
| 13:57 | <hsivonen> | SimonSapin: Characters ")]}" at the start of the file before normal JSON content |
| 13:58 | <hsivonen> | SimonSapin: in order to make sure the file is *not* a valid JS program |
| 13:58 | <Lachy> | hsivonen, isn't the whole point of JSON supposed to be that it is syntactically valid JavaScript? |
| 13:59 | <Lachy> | which sites prepend such characters to their JSON? |
| 13:59 | <hsivonen> | Lachy: well, JSON works independent of eval nowadays (and also in non-JS languages) |
| 14:00 | <Lachy> | yeah, I know. But JSON.parse() doesn't support prepending )]}, does it? |
| 14:00 | <hsivonen> | Lachy: the point of )]} is to prevent cross-side data theft by overriding JS Array and then loading the file as a script |
| 14:00 | <SimonSapin> | hsivonen: is this for security reasons as described in http://flask.pocoo.org/docs/security/#json-security ? |
| 14:01 | <hsivonen> | Lachy: it doesn't support it to my knowledge, but I haven't tested |
| 14:01 | <hsivonen> | Lachy: presumably Google uses this for source maps |
| 14:01 | <hsivonen> | Lachy: the source maps spec explicitly extends JSON like this |
| 14:01 | <hsivonen> | SimonSapin: yes |
| 14:02 | <hsivonen> | the source maps spec could use some Hixie-style spec writing. I will have to send some feedback. |
| 14:02 | <Lachy> | I don't know what source maps is. |
| 14:04 | <Lachy> | found this. Reading. http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ |
| 14:04 | <hsivonen> | yeah, that |
| 14:20 | <Lachy> | so I'm now looking into rewriting the about: URI spec properly (since the IETF has now taken it in the wrong direction). |
| 14:21 | <Lachy> | I need to figure out a term to use, instead of "reserved about URI", which means any URI defined by a specification for use in a defined context, but where it doesn't suggest any kind of exclusivity of that URI for that spec. |
| 14:26 | <Lachy> | I'm also defining it such that all about: URIs other than about:blank are non-dereferencable, outside of application-specific uses, which avoids any possible conflict of two specs using the same about: URI, and thus removing any need for a normative registry.. |
| 15:02 | <matjas> | TIL about the “octal escapes in regular expression literals” compatibility requirement for JavaScript: http://mathias.html5.org/specs/javascript/#octal-escapes-in-regular-expression-literals |
| 15:15 | <Hixie> | Lachy: how on earth did the ietf manage to screw up something as simple as about: ??? |
| 15:16 | <Hixie> | zcorpan: i'm literally working on a fix to the bug issue today (spent most of yesterday on it too) |
| 15:16 | <Hixie> | zcorpan: (writing a script that will clone the bugs) |
| 15:17 | <Lachy> | well, they define things that just don't match reality. percent-encoding is not supported, for example, and yet is defined in the spec. I would have changed it, but the feedback was handled around the time someone else took over editing. |
| 15:18 | <Lachy> | they also introduced a silly registry that gives exclusivity of a given about: URI to the first spec that defines it, rather than realising that independent uses of the same token in different specs doesn't conflict in any case. |
| 15:18 | <Lachy> | they also now fail to define how about:blank is handled. |
| 15:19 | <Ms2ger> | In their defense, nobody knows how about:blank needs to be handled |
| 15:20 | <Lachy> | so I think about: URIs, at least for use in specifications, are to be handled as opaque identifiers, rather than real URLs. |
| 15:20 | <Lachy> | Ms2ger, it needs to be handled as an opaque identifier not subject to URL normalisation, and behaves as though it returns an empty UTF-8 encoded HTML document. |
| 15:22 | <Lachy> | <iframe src="about:blan%6B"> is not the same as <iframe src="about:blank"> in any implementation. |
| 15:22 | <Ms2ger> | But clearly it *should* be! |
| 15:24 | <Lachy> | that depends on the reasons for browsers not applying any normalisation. Boris sent feedback before to the IETF list about this, and the potential for security implications for changing it. |
| 15:26 | <Lachy> | Ms2ger, also, despite the about: spec being available and saying that for a long time now, not one browser has changed. So I'd rather have a spec that documents reality. |
| 15:26 | <hsivonen> | when in doubt, let bz take precedence over the IETF |
| 15:26 | <Ms2ger> | s/the IETF/everyone else/, pretty much |
| 16:06 | <Hixie> | Lachy: good times |
| 16:33 | <hober> | Lachy: TabAtkins_ apparently managed to register about:invalid with the iana folks |
| 16:46 | <TabAtkins_> | Yup, it was pretty easy. |
| 17:05 | <Lachy> | hober, yes, I know. I saw that. |
| 17:23 | <TabAtkins_> | zcorpan: Assuming you read logs when you return for a few weeks, looks like I was wrong. a00000 will indeed be handled correctly by your quirk. |
| 17:29 | <annevk> | hober: TabAtkins_: fwiw, CSS should use about:blank, just like every other place where we lack a base URL |
| 17:30 | <annevk> | Lachy: Ms2ger: %-normalization does not appear to happen in the browser, so supporting just "about:blank" should be pretty trivial |
| 17:30 | <annevk> | Lachy: Ms2ger: especially once the URL specification is somewhat more in shape, though not sure how much of that I'll do during vacation, other than a bit of planning |
| 17:31 | <TabAtkins_> | annevk: No can do. That's a valid HTML page, which won't do what we want if we, say, de-magicify iframes into CSS. |
| 17:31 | <annevk> | it's not valid and I'm not sure what you mean |
| 17:31 | <TabAtkins_> | Hm? about:blank is a perfectly valid page. |
| 17:32 | <annevk> | not validator valid |
| 17:32 | <TabAtkins_> | Who cares about that? |
| 17:32 | <annevk> | dunno, but I'm not sure what you mean |
| 17:32 | <scott_gonzalez> | Is there a way to prevent a browser from displaying options for <input list> or would you need to remove the list attribute? |
| 17:32 | <TabAtkins_> | I mean that it's a resolveable URL that returns an HTML page. |
| 17:33 | <annevk> | scott_gonzalez: you'd need to remove the attribute |
| 17:33 | <Lachy> | annevk, right, which is why I think percent normalisation should be abandoned. It might be easier to just say that when used by a specification in a specific context, they are non-dereferencable magic tokens that look like URLs, but which aren't really. Except for about:blank, no other about: URI actually needs to refer to any specific resource. |
| 17:33 | <annevk> | TabAtkins_: what you mean with de-magicify iframes |
| 17:33 | <TabAtkins_> | The point of the default value for attr(foo url) is that it shouldn't every be dereferenceable, no matter what context it appears in. |
| 17:33 | <TabAtkins_> | annevk: Like, "content: frame(http://foo);"; |
| 17:34 | <scott_gonzalez> | Is there anything documenting how to search against the options or is it up to the UA? |
| 17:34 | <annevk> | TabAtkins_: why not? |
| 17:34 | <annevk> | scott_gonzalez: up to the UA |
| 17:34 | <TabAtkins_> | Because then it's not a very good default value? Also: symmetry. |
| 17:34 | <annevk> | TabAtkins_: symmetry would be following the rest of the platform |
| 17:34 | <scott_gonzalez> | annevk: Do you think in makes sense for @list to be ignored for @autocomplete=off? |
| 17:35 | <annevk> | scott_gonzalez: no, autocomplete is orthogonal |
| 17:35 | <Hixie> | what's about:invalid? |
| 17:35 | <Lachy> | about:invalid in CSS Values spec |
| 17:35 | <annevk> | Hixie: same as about:blank but without the content-type |
| 17:35 | <TabAtkins_> | Hixie: I just got it registered. Guaranteed non-dereferencable url. |
| 17:35 | <Hixie> | ah |
| 17:35 | <scott_gonzalez> | annevk: Really? @list seems to me like a way to build a specific set of autocomplete options. |
| 17:35 | <Hixie> | in other news, i am about to start testing my script for cloning htmlwg bugs into whatwg bugs (the script to do the opposite is next, but the needs are different so i'm doing them in two different steps) |
| 17:36 | <annevk> | scott_gonzalez: autocomplete relates to UA-autocomplete, not developer-autocomplete |
| 17:36 | <annevk> | Hixie: is the opposite needed? |
| 17:36 | <Hixie> | annevk: well i assume the htmlwg doesn't want to lose all the bugs, i mean, the bugs apply to their spec too |
| 17:37 | <Hixie> | MikeSmith: i'll let you know when i'm ready to just do a batch job, but for now since i'm doing these one bug at a time i think it's ok to leave the bugmail turned on |
| 17:37 | <annevk> | yeah I guess, don't really see the point in having both specs if they're not edited by the same person |
| 17:37 | <Hixie> | incidentally, i am calling this "operation convergence". |
| 17:37 | <Hixie> | annevk: no argument from me there, but that's up to them |
| 17:38 | <annevk> | Hixie: sounds like a name straight from Arrested Development |
| 17:38 | <Lachy> | TabAtkins_, just curious what you think about the %-encoding issue. Should about:invali%64 work in CSS, or would you rather it be just an opaque identifier that must match "about:invalid" to be valid? |
| 17:38 | <TabAtkins_> | Lachy: I have absolutely no opinion on this. |
| 17:38 | <Lachy> | ok |
| 17:38 | <annevk> | Lachy: I think everything after about: should just be treated as a literal |
| 17:38 | <annevk> | Lachy: apart from normalization that is done by the URL parser |
| 17:39 | <annevk> | Lachy: e.g. turning " " into "%20" and such |
| 17:39 | <Hixie> | ok. |
| 17:39 | Hixie | pushes the button to run the first bug through |
| 17:40 | <annevk> | Tabatkins: it's still not really clear to me why about:blank is not okay |
| 17:40 | <annevk> | Tabatkins: it's used e.g. for Document objects created by createDocument or createHTMLDocument |
| 17:40 | <annevk> | it's used by <iframe>s |
| 17:40 | <annevk> | etc. |
| 17:40 | <Tabatkins> | Those are trying to create HTML documents, yes. |
| 17:40 | <Hixie> | ok. this is what my script does for bugs that don't need cloning but don't apply to whatwg bugs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14028 |
| 17:40 | <annevk> | no they're not |
| 17:40 | <Hixie> | that looks ok |
| 17:40 | Hixie | pushes the button again |
| 17:42 | <Hixie> | this is what bugs look like when they are cloned: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17769 |
| 17:43 | Hixie | makes the lines between comments longer for aesthetic reasons |
| 17:44 | <annevk> | does not look too bad |
| 17:44 | <Tabatkins> | annevk: The problem that I alluded to with my "symmetry" comment is that we have mechanisms in CSS now that have special behavior for "invalid" URLs, that don't dereference to a resource of the expected type (the image() function). |
| 17:44 | <annevk> | but it's going to be confusing when people add comments all over |
| 17:45 | <Hixie> | annevk: i'm very open to suggestions for making it better |
| 17:45 | <Tabatkins> | annevk: It's reasonable to assume that, in the future, if we have properties that expect to take a URL pointing to an HTML page, that we might have similar functionality. |
| 17:45 | <Tabatkins> | annevk: So, for symmetry, might as well claim a URL up-front that will work for all media types. |
| 17:45 | <annevk> | Tabatkins: why would it ever point to about:blank directly? |
| 17:46 | <annevk> | Tabatkins: could you give an example? |
| 17:46 | <Tabatkins> | Because of attr(foo url), when the element doesn't have a "foo" attribute. |
| 17:46 | <annevk> | Tabatkins: ooh, why wouldn't you fallback to nothing? |
| 17:46 | <Tabatkins> | What is "nothing"? |
| 17:47 | <annevk> | Tabatkins: is this mainly about the computed value? |
| 17:47 | <Tabatkins> | Yeah. |
| 17:48 | <annevk> | Tabatkins: wouldn't the computed value be "foo"? |
| 17:48 | <Hixie> | hm, bug in my script; it didn't properly update the previous bug |
| 17:48 | <Hixie> | why not |
| 17:49 | <Tabatkins> | annevk: No, that would be weird. It would mean that attr(foo url) computes to either a string or a url, depending on whether the attribute exists. |
| 17:49 | <Tabatkins> | We can't do useful type-checking with that. |
| 17:49 | <Tabatkins> | And computing to url(foo) is no good either, because that's potentially a valid resource. |
| 17:51 | <annevk> | thanks for explaining |
| 17:51 | <Tabatkins> | It makes sense now? |
| 17:51 | <annevk> | not sure whether it was worth a new URL, but the explanation makes sense |
| 17:52 | <Tabatkins> | kk, good enough. |
| 17:58 | Hixie | fixes bug and pushes button again |
| 17:59 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=10824 became https://www.w3.org/Bugs/Public/show_bug.cgi?id=17770 |
| 18:00 | <Hixie> | looks like that worked, reassignment of the original and everything |
| 18:05 | <Hixie> | ok last test: https://www.w3.org/Bugs/Public/show_bug.cgi?id=11004 cloned to https://www.w3.org/Bugs/Public/show_bug.cgi?id=17771 |
| 18:05 | <Hixie> | that one shows some of my attempts to be clever in the cloning |
| 18:05 | <Hixie> | (compare the comments) |
| 18:06 | <Hixie> | ok. this script seems to work. let's work on the script for the other direction now. |
| 18:07 | <Ms2ger> | Killing the "EDITOR'S RESPONSE" boilerplate and the "mass-moved component" comments? |
| 18:07 | <Hixie> | and stripping quotations from comments for the form ">lots of quotations from immediately prior comment\ncomment" |
| 18:08 | <Ms2ger> | What's the other direction for? |
| 18:11 | <Hixie> | the bugs that are in the 'other hixie drafts' component because they were filed from the whatwg side, but that apply to the htmlwg deliverables |
| 18:14 | <Ms2ger> | Is there anyone who's going to look at them? |
| 18:16 | <Hixie> | how do you mean? |
| 18:16 | <Ms2ger> | At the bugs in the htmlwg components |
| 18:17 | <Hixie> | the chairs have said that they are going to find an editor who is going to do what i was doing but with an eye to going to REC, so i presume so |
| 18:17 | <Hixie> | it's what their process requires, no? |
| 18:18 | <Hixie> | it would be pretty disastrous to the htmlwg spec if they just stopped fixing the problems with it, not to mention being a violation of both the wg's process and the w3c's process |
| 18:20 | <Ms2ger> | Well... |
| 18:20 | <Ms2ger> | Yes |
| 18:20 | <Hixie> | anyway, that's their problem |
| 18:20 | <Ms2ger> | Otoh, the W3C just published an XHTML2 module |
| 18:21 | <Hixie> | seriously? |
| 18:22 | <Ms2ger> | http://www.w3.org/TR/2012/CR-role-attribute-20120712/ |
| 18:22 | <Hixie> | ... |
| 18:23 | <annevk> | well also the HTML Media Capture draft |
| 18:23 | <annevk> | which is really just a new attribute for <input> |
| 18:24 | <annevk> | Tabatkins: I think in the specific case where you want to represent a network error via a URL and not have the URL for base URL purposes something like about:invalid is probably okay |
| 18:25 | <annevk> | Tabatkins: it seems somewhat likely there's a precedent for that somewhere, but maybe not |
| 18:25 | <Tabatkins> | Yeah, that's basically the intent here. |
| 18:25 | <Ms2ger> | Oh, and I hadn't even seen http://www.w3.org/MarkUp/Forms/2012/WD-xforms20-20120628/ yet |
| 18:25 | <annevk> | Ms2ger: there was also an XForms module I think |
| 18:26 | <Ms2ger> | Anyway, I don't really care what the W3C does anymore |
| 18:26 | <Hixie> | annevk: btw is anyone implementing capture="" yet? if they are we should just spec it |
| 18:27 | <annevk> | I thought Android had it, but I'm not sure if Chrome Android has it too |
| 18:27 | <annevk> | beverloo? |
| 18:29 | <Hixie> | if it's just one vendor then it's not so interesting |
| 18:31 | <Hixie> | annevk: btw is this your bug? https://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 |
| 18:32 | <annevk> | it's from simon |
| 18:33 | <annevk> | you can reassign to the URL spec |
| 18:33 | <annevk> | it's going to be solved by the whitelist of hierarchical schemes |
| 18:33 | <annevk> | I can reassign too |
| 18:35 | <annevk> | Hixie: maybe instead of "other Hixie drafts" we should ask for a "WHATWG" or "WHATCG" product? |
| 18:36 | <annevk> | Hixie: and then have HTML / Encoding / Fullscreen / Quirks there |
| 18:37 | <Hixie> | i'd rather not have to fix all my scripts to use the new product/component |
| 18:38 | <Hixie> | but i can certainly see the logic |
| 18:38 | <Hixie> | especially for the other drafts |
| 18:38 | <Hixie> | i guess it wouldn't be so bad, not that many scripts to update really |
| 18:38 | <Hixie> | sure |
| 18:38 | <Hixie> | let's do that |
| 18:38 | <Hixie> | let's wait til after this migration though |
| 18:39 | <annevk> | sure, I think it'll also help people filing bugs against WHATWG work |
| 18:39 | <Hixie> | yeah |
| 18:39 | <hober> | word |
| 18:41 | <annevk> | zewt: are you around? |
| 18:41 | <Hixie> | (incidentally, i'm not changing the qa contact field during this, but i guess after the migration we should change that too) |
| 18:43 | <Hixie> | ok looks like part 2 is ready too |
| 18:43 | <Hixie> | MikeSmith: ok i'm ready whenever you are |
| 18:45 | <Hixie> | back in bit, lunch |
| 18:55 | <annevk> | zewt: added a comment to the bug instead |
| 18:59 | <jtcranmer> | is there any sort of spec for txt-to-html conversion or vice versa? |
| 19:01 | <SimonSapin> | jtcranmer: there are many text-based lightweight markup languages that can convert to HTML: markdown, restructuredText, … |
| 19:01 | <jtcranmer> | that doesn't answer my question :-) |
| 19:03 | <SimonSapin> | then, what do you mean by txt-to-html? |
| 19:03 | <annevk> | jtcranmer: there's no standardized way other than lots of de facto standards |
| 19:03 | <jtcranmer> | there are de facto standards at least for things like *bold* /italics/ _underline_ |code| |
| 19:04 | <SimonSapin> | yes, and markdown formalizes them somewhat |
| 19:04 | <jtcranmer> | and I've noticed that things like copying HTML and pasting as plain text tend to do things like turn <ol> into # and <ul> into * or similar ventures |
| 19:05 | <SimonSapin> | there are many variants, like `code` instead of |code| |
| 19:05 | <SimonSapin> | if you pick on precisely, you get something like markdown |
| 19:05 | <SimonSapin> | http://daringfireball.net/projects/markdown/syntax |
| 19:07 | <Tabatkins> | Yes, Markdown is generally accepted as the "standard" txt-markup language now. There are several incompatible extensions, but the core is stable. |
| 19:08 | <jtcranmer> | how about the other direction? |
| 19:09 | <SimonSapin> | it has been done, but it is always lossy |
| 19:09 | <jtcranmer> | I don't doubt that it is |
| 19:24 | <Tabatkins> | It's actually a good bit easier. Just look up what markdown can encode, then reverse it in the obvious way. |
| 19:25 | <Tabatkins> | <h1>foo</h1> becomes "foo\n===", etc. |
| 19:25 | <SimonSapin> | Tabatkins: easier because we already have HTML parsers? |
| 19:25 | <Tabatkins> | Yes, it's a simple tree-walk then. |
| 19:26 | <Tabatkins> | I'm assuming this is done in the browser. |
| 19:26 | <Tabatkins> | Outside of it, the HTML parser is harder than the Markdown parser. ^_^ |
| 19:27 | <SimonSapin> | okay. I guess md-to-html is alsa just a tree-walk once the Markdown is parsed |
| 19:27 | <SimonSapin> | also* |
| 19:27 | <Tabatkins> | Well, sure. |
| 19:28 | <annevk> | http://softwaremaniacs.org/playground/showdown-highlight/ |
| 19:30 | <Hixie> | the official way to convert text/plain to HTML is <pre>... :-) |
| 19:31 | <Tabatkins> | <plaintext>, you mean. |
| 19:31 | <Tabatkins> | Also, <xmp> is better for actual text/plain. |
| 19:31 | <Hixie> | that's the unofficial way |
| 19:31 | <Tabatkins> | ;_; |
| 19:32 | <jtcranmer> | Hixie: that's how you should display a text/plain as a DOM |
| 19:32 | <Tabatkins> | annevk: Hrm, the default styling there doesn't do anything special for blockquotes, which looks confusing. |
| 19:32 | <MacTed> | <pre> fails at text/plain conversion to HTML, as there's no line-wrapping within <pre> elements |
| 19:32 | <jtcranmer> | Hixie: for email clients receiving a text/plain, requirements are slightly different |
| 19:32 | <Tabatkins> | MacTed: <pre style="whitespace: pre-wrap;"> |
| 19:34 | <MacTed> | Tabatkins - I believe that will work in many (most) browsers. but it's a different way than <pre>. |
| 19:34 | <Hixie> | jtcranmer: an e-mail client receiving text/plain e-mail doesn't have to convert to HTML, it has to convert to pixels. |
| 19:34 | <Hixie> | (typically) |
| 19:34 | <Hixie> | there's no line wrapping in text/plain either :-) |
| 19:35 | <MacTed> | Hixie - what the rendering engine does with text/plain is outside of scope. <pre> mandates no wrapping during render. text/plain does no such thing. |
| 19:36 | <Hixie> | <pre> doesn't mandate anything on rendering |
| 19:36 | <Hixie> | you could render <pre> contents to a 3d orange and it wouldn't be non-compliant |
| 19:36 | <Hixie> | anyway |
| 19:37 | Ms2ger | throws a 3d orange at Hixie |
| 19:37 | <Hixie> | any browser vendors other than chrome looking at this autocompletetype thing? |
| 19:37 | <Ms2ger> | autowhat? |
| 19:38 | <Hixie> | chrome proposal from a while back about a way to do better autofill |
| 19:47 | <Hixie> | anyone from mozilla or opera have an opinion on it? |
| 19:47 | <Hixie> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Dec/0194.html was the original e-mail |
| 19:48 | <Ms2ger> | volkmar, ^ |
| 19:48 | <Ms2ger> | I don't care much for it |
| 19:51 | <rniwa> | sigh... HTMLCollection is such a mess. |
| 19:51 | <Ms2ger> | s/HTMLCollection/the web/ |
| 19:51 | <rniwa> | why does HTMLAllCollection::namedItem returns another HTMLAllCollection? |
| 19:51 | <rniwa> | why can't it be HTMLCollection |
| 19:52 | <rniwa> | or NodeList |
| 19:52 | <Ms2ger> | I dunno |
| 19:52 | Ms2ger | looks what Gecko does |
| 19:52 | <rniwa> | HTMLOptionsCollection::namedItem returns live NodeList |
| 19:52 | <rniwa> | and HTMLFormCollection::namedItem returns RadioNodeList |
| 19:52 | <rniwa> | HTMLPropertiesCollection::namedItem returns PropertyNodeList |
| 19:55 | <hsivonen> | Hixie: reinventing the RFC WF2 used to reference, eh? |
| 19:55 | <hsivonen> | (although in fairness, decoupling the autofill semantic from the field name is slightly different) |
| 19:56 | <Hixie> | hsivonen: yeah |
| 19:56 | <Ms2ger> | rniwa, afaict, Gecko just goes with the usual NodeList-HTMLCollection hybrid |
| 19:57 | <rniwa> | Ms2ger: we just return static node list LOL |
| 19:57 | <Hixie> | hsivonen: they had some good reasons for thinking the rfc failed due to design problems and not due to lack of need, can't remember if they told me them in person or talked about it on the list |
| 19:57 | <hsivonen> | Hixie: ok |
| 19:57 | <Tabatkins> | Should we be prefixing the new path apis on canvas? |
| 19:57 | <Hixie> | tano |
| 19:57 | <Hixie> | er |
| 19:57 | <Hixie> | Tabatkins: no |
| 19:57 | <Tabatkins> | kk |
| 19:58 | <hsivonen> | Tabatkins: prefixing in what way? |
| 19:58 | <Hixie> | i guarantee that any spec i write will not conflict with implementations, either by renaming the things in the spec or aligning with implementations directly |
| 19:58 | <Hixie> | so there's never any need to prefix stuff i spec |
| 19:58 | <Tabatkins> | hsivonen: webkitPath(), etc. |
| 19:58 | <Ms2ger> | Let's rename some more flexbox stuff |
| 19:58 | <Tabatkins> | VIOLENCE |
| 19:59 | <Hixie> | lol |
| 19:59 | <hsivonen> | Tabatkins: I wish by now it was clear that the answer to "should we vendor prefix?" is "NOOOO!" :-( |
| 19:59 | <Ms2ger> | But order is such a bad name... |
| 20:00 | <Ms2ger> | Hmm |
| 20:00 | <Ms2ger> | document.all.item("item") |
| 20:00 | <Ms2ger> | I bet Gecko doesn't handle that right |
| 20:00 | <Ms2ger> | Otoh, I don't care |
| 20:00 | <annevk> | Tabatkins: for some reason that reminds me of http://ln.hixie.ch/?start=1063663989&count=1 |
| 20:01 | <Ms2ger> | "Margin collapsing is now well defined." |
| 20:01 | <Tabatkins> | Oh, the naivete of youth... |
| 20:01 | <hsivonen> | lol |
| 20:01 | <annevk> | Ms2ger: where is that from? |
| 20:01 | <Ms2ger> | annevk, ... guess? |
| 20:01 | <Tabatkins> | That post you linked. |
| 20:01 | <annevk> | oh doh |
| 20:02 | <annevk> | now you reminded me of the one where Hixie is a fan of XHTML 2.0 |
| 20:02 | <hsivonen> | how many Last Calls did CSS 2.1 have? |
| 20:02 | <Tabatkins> | I consider it just one long 8-year LC. |
| 20:03 | <Hixie> | hey, margin collapsing at that point _was_ well defined compared to before |
| 20:03 | <Hixie> | it was defined in like 4 hand-wavy lines before that point |
| 20:03 | <Ms2ger> | "compared to before" is pretty essential |
| 20:04 | <Hixie> | it's like html parsing before, and after, the month i spent first speccing it |
| 20:04 | <Hixie> | sure, it wasn't perfectly "well defined" after either, but compared to before, hell |
| 20:05 | <Hixie> | ok let's see. i have a bunch of features that are only requested by one vendor but which nobody seems opposed to. if i do one such feature per vendor, that should be considered fair, right? |
| 20:05 | <Hixie> | apple want getImageDataHD |
| 20:05 | <Hixie> | chrome want like a zillion things, but let's start with autocompletetype |
| 20:06 | <Hixie> | mozilla want... data: in web workers was a mozilla request right? |
| 20:06 | <Ms2ger> | No, Opera |
| 20:06 | <espadrine> | The autocompletetype effort is very good |
| 20:06 | <Ms2ger> | At least, I'm going to put it on Opera's bill |
| 20:06 | <espadrine> | do they want it in the html spec? |
| 20:06 | <espadrine> | it feels like it doesn't belong |
| 20:06 | <Hixie> | ok, so what does mozilla want that nobody else wants |
| 20:06 | <Ms2ger> | The entire output of the WebAPI WG |
| 20:07 | <Hixie> | espadrine: yeah, it'd be a small subsection in the web forms section |
| 20:07 | <Hixie> | Ms2ger: i mean, that goes in the whatwg spec |
| 20:07 | <Hixie> | oh the plugin click-to-play thing |
| 20:07 | <Hixie> | that's a mozilla thing |
| 20:07 | <Hixie> | ok |
| 20:07 | <Ms2ger> | That's a thing by some Mozilla guy ;) |
| 20:07 | <Ms2ger> | And I think he retracted it |
| 20:08 | <Hixie> | and what does Microsoft want |
| 20:08 | <Hixie> | removeHitRegion? |
| 20:08 | <espadrine> | it looks sort of like scheme.org… but having a subsection in the spec makes it visible |
| 20:08 | <Hixie> | espadrine: i'd probably put scheme.org in the html spec if they asked :-) |
| 20:09 | <Hixie> | schema.org? |
| 20:09 | <Hixie> | whatever it's called |
| 20:09 | <Hixie> | wait, you mean the microdata thing for search engines right? |
| 20:09 | <Ms2ger> | Meh |
| 20:09 | <espadrine> | yep, misspelled ;) |
| 20:09 | <Hixie> | k |
| 20:09 | <Ms2ger> | We already implemented your microdata API |
| 20:09 | <Hixie> | anyway, i'd probably put that in if they wanted it in the html spec, there are other vocabs in there |
| 20:09 | <Ms2ger> | About which I note there are some outstanding bugs ;) |
| 20:10 | <Hixie> | i'm stuck on bugs until MikeSmith gets online |
| 20:10 | <Hixie> | anyway bugs aren't controversial |
| 20:10 | <Hixie> | everyone wants them fixed, generally |
| 20:11 | <annevk> | MikeSmith is prolly ~5h away from being online |
| 20:11 | <annevk> | espadrine: why should it not be in HTML? |
| 20:11 | <rniwa> | Ms2ger: i've sent an angry email about htmlcollection now. |
| 20:11 | <Ms2ger> | I noticed :) |
| 20:12 | <Ms2ger> | Oh, we want window.scrollMax* |
| 20:12 | <espadrine> | annevk: maybe it should, I'm not sure |
| 20:12 | <annevk> | espadrine: that and a wiki page for extensions that get later folded in if successful seems like a rather good model |
| 20:13 | <Hixie> | scrollMax => CSSOM |
| 20:14 | <Ms2ger> | Might as well say /dev/null |
| 20:14 | <espadrine> | annevk: as long as those extensions are not vendor-prefixed |
| 20:14 | <annevk> | Ms2ger: didn't quite realize it would be this bad :( |
| 20:14 | <annevk> | espadrine: uhuh :) |
| 20:14 | <Tabatkins> | I'm annoyed, but I'm giving them til the timeline that Shane gave me expires. |
| 20:15 | <Tabatkins> | Which is in August. |
| 20:16 | <Ms2ger> | When did they claim they would edit? |
| 20:16 | <Ms2ger> | January? |
| 20:17 | <Tabatkins> | Don't recall. |
| 20:17 | Ms2ger | doesn't believe anything useful will happen on that spec |
| 20:18 | <Hixie> | ok i can't get hold of josh and the thread on click-to-play does give a plausible alternative that involves no spec changes |
| 20:18 | <Tabatkins> | If nothing useful happens, I'll take it. But like I said, I'm still waiting for my coworker to exceed his timeline. ^_^ |
| 20:18 | <Hixie> | so... what else do mozilla people want |
| 20:20 | <annevk> | Ms2ger: it was very shortly after http://lists.w3.org/Archives/Public/www-style/2011Nov/0782.html |
| 20:20 | <annevk> | Ms2ger: glazou was so happy with the new editors he tweeted enthusiastically about them before anything was done |
| 20:20 | <annevk> | Ms2ger: but you know, it's only over half a year later, give them some time |
| 20:22 | <Tabatkins> | "all the email addresses in the registries have had |
| 20:22 | <Tabatkins> | their "@" symbols automatically converted into ampersands in order to |
| 20:22 | <Tabatkins> | thwart harvesting. |
| 20:22 | <Tabatkins> | wut |
| 20:23 | <Ms2ger> | Hixie, we'd like you to define table layout? :) |
| 20:23 | <annevk> | if url contains ietf.org look for "&" |
| 20:23 | <annevk> | or iana.org |
| 20:23 | <annevk> | ooh |
| 20:23 | <annevk> | is that how it works |
| 20:23 | <annevk> | please define CSS Hixie |
| 20:24 | <annevk> | I'm soon unemployed, but the people will appreciate it |
| 20:24 | <Tabatkins> | annevk: What actual job did you end up taking? The page you linked to isn't in English. ^_^ |
| 20:25 | <Ms2ger> | Learn Dutch :) |
| 20:25 | <annevk> | Tabatkins: http://robbertbroersma.nl/ looks English to me |
| 20:25 | <Tabatkins> | ...huh. I didn't see the blog posts before. |
| 20:26 | <annevk> | Tabatkins: but I'm going to be a co-founder of sorts |
| 20:26 | <Ms2ger> | Working on XSLT? |
| 20:33 | <annevk> | Ms2ger: not planning on it, but maybe, we'll see |
| 20:35 | <annevk> | Ms2ger: planning on having fun, writing specs, making our idea successful, and enjoying the freedom of not representing anyone |
| 20:35 | <Ms2ger> | Join Mozilla, you don't need to represent us either ;) |
| 20:36 | <annevk> | would've been the same for Google |
| 20:37 | <Ms2ger> | Yeah, but we're good, and they're evil :) |
| 20:37 | <Tabatkins> | Hey, fuck you. ^_^ |
| 20:37 | <Ms2ger> | <3 Tabatkins |
| 20:38 | <Hixie> | Ms2ger: i think you're missing the part where i edit the HTML spec... |
| 20:38 | <Ms2ger> | Hixie, can't I troll in here? :( |
| 20:39 | <Hixie> | sure you can troll |
| 20:39 | <Hixie> | and tab can say fuck you too :-) |
| 20:39 | <Ms2ger> | I noticed! ;) |
| 20:40 | <espadrine> | annevk: which idea is that? |
| 20:40 | <Hixie> | (oh, you meant telling me to spec css was trolling. i thought you were referring to saying google was evil.) |
| 20:40 | <Hixie> | (my bad) |
| 20:40 | <Ms2ger> | No, mine :) |
| 20:40 | <Hixie> | ok well i can't find anything mozilla wants |
| 20:40 | <Hixie> | so i guess you guys get nothing |
| 20:40 | <Ms2ger> | I didn't realize you were talking about CSS |
| 20:40 | <annevk> | espadrine: dunno really how much we're telling, I'm on vacation and we're prolly not properly founded until October or so |
| 20:41 | <espadrine> | annevk: I see. Good luck in your venture then! :) |
| 20:41 | <Hixie> | Ms2ger: so basically we have no idea what either of us are saying. sounds like this conversation is going swimmingly. :-P |
| 20:41 | <Ms2ger> | :D |
| 20:41 | <hober> | :) |
| 20:41 | <Hixie> | anne: wait hold on, hold on |
| 20:42 | <Hixie> | annevk: that site says XSLT on it |
| 20:42 | <Hixie> | annevk: twice |
| 20:42 | <Hixie> | annevk: in big letters |
| 20:42 | <hober> | Hixie: re: autocompletetype="", we like the overall idea of (long-term) reducing the pain of autofill code |
| 20:42 | <annevk> | Hixie: :) Robbert is a fan |
| 20:42 | <Hixie> | ...and you want to cofound something with him? o_O |
| 20:42 | <hober> | hahahha |
| 20:42 | <Ms2ger> | Hixie, I didn't miss that you edit the HTML spec, but if you're ever looking for more work to do... CSS is an option :) |
| 20:43 | <Hixie> | Ms2ger: i'm looking for an HTML feature that mozilla wants because i'm doing the rounds of feature requests and granting one to each vendor that no other vendor is super-eager about |
| 20:43 | <espadrine> | I wondered how long it would take before some XSLT trolling… |
| 20:43 | <Hixie> | Ms2ger: (not those that other vendors are against) |
| 20:44 | <Ms2ger> | Yeah |
| 20:44 | <annevk> | Hixie: looking forward to it even :) |
| 20:44 | <Ms2ger> | Hixie, can we keep that for a future feature request? :) |
| 20:45 | <Hixie> | Ms2ger: nah :-P |
| 20:45 | <Ms2ger> | XBL2? :) |
| 20:45 | <Hixie> | already specced that |
| 20:45 | <Ms2ger> | And I guess everyone else hates it |
| 20:45 | <Hixie> | nah only dglazkov hates it :-P |
| 20:46 | <Hixie> | man, of the four features here, _two_ are canvas-related |
| 20:46 | <Hixie> | ain't that always the way |
| 20:47 | <hsivonen> | in case anyone has opinions about http vs. internal declaration precedence for source maps, now is your chance to comment on https://bugzilla.mozilla.org/show_bug.cgi?id=765993 |
| 20:47 | <Ms2ger> | Weren't you going to wait with more canvas stuff until we implemented any of the new stuff? :) |
| 20:47 | <Hixie> | Ms2ger: i was |
| 20:48 | <Hixie> | hsivonen: what's a source map? |
| 20:48 | <espadrine> | source map: file that contains data to go from original minified JS to readable JS |
| 20:48 | <espadrine> | or from coffeescript to JS |
| 20:48 | <espadrine> | it's useful for devtools, mainly |
| 20:49 | <Hixie> | oh like symbol maps for compiled binary code? |
| 20:49 | <espadrine> | exactly |
| 20:49 | <hsivonen> | Hixie: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?_escaped_fragment_= |
| 20:50 | <Hixie> | i had no idea some people used the term "source map" instead of "symbol map", weird |
| 20:50 | <Hixie> | sounds like a useful feature though! |
| 20:51 | <Ms2ger> | Want to spec it? :) |
| 20:52 | <Hixie> | hsivonen: is anyone gonna use the http header? seems like a pointless feature |
| 20:53 | <Hixie> | hsivonen: internal makes a lot of sense (p.s. i'd still love to see a filename/lineno pragma for validator.nu) |
| 20:53 | <espadrine> | hsivonen: having the X in X-SourceMap is strange |
| 20:53 | <Ms2ger> | espadrine, that's what hsivonen said :) |
| 20:53 | <Hixie> | hober: i assume you want backingStorePixelRatio to return the ratio of device pixels to coordinate space units, not to CSS pixels, right? |
| 20:53 | <espadrine> | Ms2ger: Oops. Didn't see :) |
| 20:53 | <Hixie> | er, s/device pixels/backing store pixels/ |
| 20:53 | <hsivonen> | Hixie: good point. dunno |
| 20:54 | <annevk> | hsivonen: why does the header have an X- prefix? |
| 20:54 | <annevk> | hsivonen: http://tools.ietf.org/html/rfc6648 |
| 20:54 | <hsivonen> | annevk: I don't know, but the usual guess applies |
| 20:55 | <zewt> | annevk: i'm here in case you don't want to spam the bug btw |
| 20:55 | <hsivonen> | annevk: cool. I didn't realize that one had gotten out of the draft stage |
| 20:55 | <annevk> | zewt: my idea is that you have a global list of identifiers |
| 20:56 | <annevk> | zewt: the identifiers have some kind of revoke flag and origin tied to them, and optionally the payload data |
| 20:56 | <annevk> | zewt: that way blob URLs always map to them and APIs don't need special knowledge about the state of blob URLs |
| 20:57 | <zewt> | not quite following ... what do you mean by "revoke flag"? |
| 20:57 | <annevk> | zewt: but if the revoke flag is set for a particular identifier parsing the URL should not work |
| 20:57 | <zewt> | if a blob URL is revoked, it simply no longer exists |
| 20:57 | <annevk> | yeah I think we should change that concept |
| 20:57 | <Hixie> | hober: also, do you want it on canvas of the 2d context? i'm guessing 2d context, since the webgl guys have their own issues on this front |
| 20:57 | <annevk> | I think it should simply fail to parse |
| 20:57 | <Tabatkins> | Hixie: Yes, definitely. |
| 20:57 | <espadrine> | hsivonen: since Chrome's implementation of source maps is not in stable builds yet, maybe we can change this before it's too late? |
| 20:57 | <annevk> | because otherwise the blob URL can no longer be fetched |
| 20:57 | <Tabatkins> | Hixie: Sorry, regarding the backingStorePixelRatio. |
| 20:57 | <annevk> | you'd need a whole bunch of special casing everywhere |
| 20:58 | <hober> | Hixie: yes to your first question |
| 20:58 | <zewt> | but you have to free up the URL at some point, or else a loop creating blob URLs would leak forever |
| 20:58 | <annevk> | zewt: it always uses the same identifier? |
| 20:58 | <hsivonen> | espadrine: oh. cool |
| 20:58 | <zewt> | no, it's different each time you create it |
| 20:58 | <annevk> | zewt: right, so you need to free up the identifier at some point |
| 20:58 | <hober> | Hixie: re: where it should hang off of, it would be nice if it were available to script before creating a canvas |
| 20:59 | <zewt> | i don't follow what all the special casing is about |
| 20:59 | <annevk> | zewt: and then the URL can succeed to parse, but simply references no existing identifier and therefore still fails |
| 20:59 | <zewt> | the only possible per-spec thing I think might be needed is saying when the reference to the underlying blob data is released (and even that might not be needed--not sure) |
| 20:59 | <Hixie> | hober: how can you know it before knowing which canvas you're asking about? or are you saying there should not be a way for UAs to do it on a per-canvas basis? |
| 20:59 | <hober> | Hixie: [also, while we're on this, i dislike the *HD names and would be happy with better ones. :)] |
| 21:00 | <zewt> | see the pseudocode in my last post (to see if we're thinking of what resolve would do in the same way)? |
| 21:00 | <annevk> | zewt: <img>.src = url; you're saying 1) that if that's a blob URL <img> somehow needs to store its payload data and 2) that when fetching it cannot fetch the blob URL but must fetch that payload data instead |
| 21:00 | Hixie | kinds likes the HD names :-P |
| 21:00 | <Hixie> | kinda, even |
| 21:00 | <hober> | Hixie: yeah, we suggested them because we couldn't come up with better, but "least bad" != good |
| 21:00 | <annevk> | zewt: so all APIs need 1) special storage and 2) special fetching |
| 21:00 | <zewt> | annevk: no, resolve would handle 1) and fetch would handle 2) |
| 21:00 | <zewt> | img doesn't care |
| 21:00 | <annevk> | zewt: how does resolve handle it? |
| 21:01 | <zewt> | see my last post on the bug |
| 21:01 | <annevk> | zewt: so you're storing the data on the URL object? |
| 21:01 | <zewt> | yeah, though it's just a string from what I understand |
| 21:02 | <annevk> | zewt: what is just a string? |
| 21:02 | <zewt> | (doesn't matter for these purposes) |
| 21:02 | <zewt> | the result of "resolve a URL" |
| 21:02 | <zewt> | not intimately familiar with that algorithm |
| 21:02 | <annevk> | it's going to be an object of some kind |
| 21:02 | <annevk> | and it's going to be called something with parsing |
| 21:02 | <hober> | Hixie: re: exposing backingStorePixelRatio in a way that doesn't require you to create a canvas first, see dino's mail here: https://www.khronos.org/webgl/public-mailing-list/archives/1206/msg00193.html |
| 21:03 | <zewt> | that's fine either way, the point is the blob data is attached to that result (which the caller API would mostly ignore, except that when it hands that URL to fetch, fetch now has access to it) |
| 21:03 | <zewt> | which encapsulates most of this into those two algorithms |
| 21:03 | <hober> | Hixie: if you do this naively, you create a huge canvas before you realize you shouldn't :( |
| 21:03 | <annevk> | zewt: I guess that works, and supposedly it's just a pointer on URL anyway so that can be shared |
| 21:04 | <annevk> | zewt: it's kind of ugly, but not more or less than what I came up with |
| 21:04 | <zewt> | yeah it's a bit of a hack but the best I've thought of |
| 21:04 | <annevk> | zewt: maybe a little more since it affects both parsing and fetching |
| 21:04 | <annevk> | but then mine changes URLs in weird ways |
| 21:04 | <zewt> | i don't fully understand your idea |
| 21:04 | <Hixie> | hober: i don't see how that contradicts the spec |
| 21:04 | <Tabatkins> | hober: Ah, so it exposes the implicit multiplier, not the final multiplier. Cool. So it's 1 on iOS devices, right? |
| 21:05 | <annevk> | global list of blob identifiers that can have a revoke flag set |
| 21:05 | <zewt> | when is that list purged? |
| 21:05 | <hober> | Tabatkins: right |
| 21:05 | <annevk> | once a blob URL is parsed that references an identifier whose revoke flag is set, it's turned into about:invalid |
| 21:05 | <Hixie> | hober: my problem is that if you are creating a canvas every few minutes, and the user is zooming every few minutes, you're going to want a different scale factor each time. |
| 21:05 | <Hixie> | hober: i guess we could say that each <canvas> gets a scale factor assigned at birth and that there's a global attribute that returns the scale factor the UA will use if you create a canvas immediately |
| 21:05 | <annevk> | zewt: same as when identifiers cease to exist now |
| 21:06 | <zewt> | "identifiers"? |
| 21:06 | <annevk> | blob:identifier |
| 21:06 | <zewt> | you mean blob URLs? |
| 21:06 | <zewt> | (sorry if I'm being thick, I'm just missing a piece somewhere) |
| 21:06 | <annevk> | a blob URL is blob: followed by the identifier |
| 21:06 | <zewt> | but that wouldn't work |
| 21:06 | <annevk> | but the identifier holds other concepts that are not part of the URL |
| 21:06 | <annevk> | such as origin |
| 21:07 | <zewt> | the URL->blob data mapping needs to outlive the blob URL itself |
| 21:07 | <annevk> | right |
| 21:07 | <hober> | Hixie: that would work for me |
| 21:07 | <annevk> | identifier->data mapping outlives the time blob URL can be successfully parsed |
| 21:08 | <zewt> | but didn't you say that the mappings would be purged when the blob URL (or "identifier"--not sure if you mean some distinction) is revoked |
| 21:09 | <annevk> | once the revocation happens the identifier's revoke flag is set which causes further parsing of blob URLs using that identifier to fail (turn into about:invalid) |
| 21:09 | <zewt> | but when are items removed from the mapping entirely? |
| 21:09 | <annevk> | but if you already have a URL object with that specific blob URL it could still be fetched |
| 21:09 | <annevk> | zewt: that's the same as your quality of implementation thingie |
| 21:10 | <zewt> | feels fuzzier, but maybe just because i don't have as much of a mental handle on it |
| 21:10 | <annevk> | afaict it's the same model |
| 21:11 | <annevk> | but I'm okay with special casing parsing, the URL object, and fetching |
| 21:11 | <zewt> | i guess i think of a list/map of stuff that you insert into as needing to remove it explicitly, where attaching data to an object just feels GC-y |
| 21:11 | <annevk> | need to find a better term for URL object, since there's also window.URL which is somewhat different |
| 21:11 | <zewt> | guess if you call it a weakmap it makes more sense |
| 21:12 | <zewt> | well anyway |
| 21:13 | <zewt> | with the URL-property approach, do you think leaving releasing to QoI is good enough? |
| 21:13 | <zewt> | one thing is that specs still need to pay attention to it, to make sure it results in the right conclusion |
| 21:15 | <zewt> | eg. that they don't accidentally require keeping blob references around longer than expected |
| 21:15 | <annevk> | I guess reloading should fail afterwards? e.g. <iframe>.contentWindow.location.reload() |
| 21:15 | <zewt> | (such as if xhr allowed calling send() multiple times per open(), that would have happened) |
| 21:15 | <zewt> | hmm |
| 21:16 | <zewt> | any time you're able to reload the data later it'd force keeping the blob around ... so it's a judgement call |
| 21:17 | <annevk> | can't fetch just free it up? |
| 21:17 | <annevk> | after fetch completes, clear it from the URL object? |
| 21:18 | <annevk> | so if the URL object is reused by the API after that, it fails |
| 21:18 | <annevk> | and if the API reuses it before the fetch completes, it works |
| 21:18 | <zewt> | i guess it could, with two caveats: 1: it'd prevent ever using it multiple times (maybe there's never any reason to) and 2: it'd still depend on QoI for freeing (because you might eg. never call xhr.send() at all) |
| 21:19 | <annevk> | well yeah, unused objects that might be used will use memory |
| 21:19 | <annevk> | not sure if there's a way around that |
| 21:19 | <zewt> | i mean, after discarding the xhr object |
| 21:19 | <zewt> | (if you call open() and then keep the xhr around forever and never send() it, yeah, keeping the blob around forever is what the user is asking for) |
| 21:20 | <annevk> | yeah the implementation would need to make sure that the objects stored on the XHR object are freed |
| 21:20 | <annevk> | including the URL object |
| 21:20 | <annevk> | and everything it has |
| 21:20 | <annevk> | that seems pretty straightforward though |
| 21:21 | <annevk> | XHR.collect() -> will collect the associated URL object which will collect itself |
| 21:21 | <zewt> | yeah |
| 21:21 | <annevk> | not sure when there would be a multiple times scenario |
| 21:21 | <zewt> | though you'd also want to release the blob ref when entering DONE, without waiting for GC (but that's also just QoI) |
| 21:22 | <annevk> | if you enter done fetch has finished and you'd be required to |
| 21:22 | <Hixie> | hm, i guess we'll need a createImageDataHD() version too |
| 21:22 | <zewt> | Hixie: webgl decided to ignore how canvas handles pixel ratios, and make everyone do it by hand :( |
| 21:23 | <zewt> | consistency smash |
| 21:23 | <annevk> | main problem: fixing the URL spec will take a while |
| 21:23 | <annevk> | but then File API has been taking a long time |
| 21:24 | <zewt> | seems like this is doable with the current resolve algorithm as-is |
| 21:24 | <zewt> | maybe not as cleanly as if it was returning a concrete object |
| 21:25 | <annevk> | oh sure, some temporary hack could be fabricated |
| 21:25 | <annevk> | not going to invest much time in that though |
| 21:25 | <zewt> | i'm just afraid that if this gets held up, the terrible "oneTimeOnly" hack in IE will get a foothold |
| 21:26 | <annevk> | I think if you add this model as a separate comment to the bug Arun should be able to define how it works in a hacky way |
| 21:26 | <annevk> | then we'll clean it up once the URL spec is further along |
| 21:27 | <zewt> | shouldn't this be defined in HTML anyway (since that's where fetch and resolve live) |
| 21:28 | <Hixie> | zewt: they're screwed, their API has assumptions in it that means they have no choice |
| 21:28 | <zewt> | Hixie: i gave them a way to do it consistently; they ignored me |
| 21:28 | <zewt> | (or at least much more consistently than what they landed on) |
| 21:50 | <annevk> | https://twitter.com/rybesh/status/223823857449041921 about teaching Microdata and RDFa |
| 21:54 | <Hixie> | annevk: he must be biased |
| 21:55 | <Hixie> | :-P |
| 21:56 | <zewt> | hmm, i don't think microtasks are right for autoRevoke, but there are some quirks with stable states too |
| 21:59 | <Tabatkins> | Ugh, the JS i18n API uses RangeError to mean "doesn't match one of the values in this enum". >_< |
| 22:01 | <Hixie> | uh |
| 22:29 | <tantek> | annevk - I've heard similar comparisons of microdata and RDFa, of course even more so I hear that they're both still too much of a bother (e.g. compared to microformats). |
| 22:30 | <tantek> | I was originally more optimistic about microdata, but it turns out it (and RDFa) suffer from the "bolt-on" problem (ala longdesc) - they're just not part of web designers' normal workflow, so they get ignored. |
| 22:30 | <tantek> | in contrast, all web designers spend time in class attributes, so to put in a few microformats classes while they're in there is anywhere from trivial to easy. |
| 22:32 | <annevk> | I find all of them too much of a bother typically :) |
| 22:32 | <Hixie> | aha, tantek! |
| 22:32 | <annevk> | haven't seen much useful stuff done with them |
| 22:33 | Hixie | agrees with anne :-) |
| 22:33 | <zewt> | as a web developer i have no idea what either of them are, and the drama around both of them makes me not very interested in finding out :) |
| 22:34 | <tantek> | indeed, if it doesn't seem useful to you, then don't bother is a reasonable short-term prioritization approach |
| 22:35 | <tantek> | annevk - "too much of a bother" - often true unfortunately, no matter what markup we're talking about (from <section> to <abbr> to RDFa) |
| 22:36 | <annevk> | yeah, I stopped using <abbr> too |
| 22:36 | <annevk> | that's something dictionaries can solve |
| 22:36 | <tantek> | it's pretty clear from years of teach web designers, that one must demonstrate that some semantic markup provides benefits to them that outweighs the "bother" in order for them to do it and keep doing it. |
| 22:37 | <annevk> | <section> I might use if I had more complex sites |
| 22:37 | <tantek> | this can be improved by increasing the benefits received, or lowering the amount of bother, or both. |
| 22:37 | <annevk> | currently using <h2> works for me |
| 22:37 | <Hixie> | i wish i had <section> available when i started the html spec |
| 22:37 | <Hixie> | that would have made moving stuff around way easier |
| 22:38 | <Hixie> | as it is now i have a horrible tangle of pragmas to bump the hx numbers up and down on output |
| 22:38 | <tantek> | with microformats 2, we're focusing first on lowering the "bother" (since that worked for microformats in the first place, as compared to things like XML data islands etc.). |
| 22:38 | <annevk> | ah yeah, for that it's super useful |
| 22:38 | <annevk> | that would be useful on the WHATWG blog too |
| 22:38 | <tantek> | does anything actually support <section> scoped Hn tags? |
| 22:38 | <annevk> | tantek: microformats though has a lot of nonsense |
| 22:38 | <annevk> | e.g. class=url on <a> |
| 22:38 | <annevk> | although I think that's being removed now |
| 22:39 | <tantek> | annevk - yeah, we tried just saying let all <a> links mean something, and that resulted in too many false positives. however, the class=url has been removed on simple hyperlinked things. |
| 22:40 | <tantek> | and I'd say your instinct is in general a good one, if some markup feels like nonsense, then avoid it. |
| 22:41 | <tantek> | annevk - what's being removed? the section scoped Hn thing? |
| 22:41 | <annevk> | learned it the hard way |
| 22:41 | <annevk> | came from the "it's in the spec so it makes sense" camp |
| 22:41 | <annevk> | tantek: making class=url optional |
| 22:44 | <annevk> | tantek: dunno about <section> scoped <h1>-<h6> apart from that not having to renumber headings would be useful |
| 22:44 | <tantek> | agreed that it would be useful. I just keep wondering if anyone is going to implement it. |
| 22:44 | <tantek> | sorry, not "useful" but rather, "less of a bother" |
| 22:44 | <annevk> | btw zewt, please don't quote in Bugzilla if it's directly in reply to the previous comment |
| 22:45 | <annevk> | tantek: dunno about that, cost is quite high, benefit not that big |
| 22:46 | <annevk> | controls are where the real benefit is at I think |
| 22:46 | <annevk> | such as <dialog> |
| 22:47 | <annevk> | some way to do a dropdown without lots of scripting would be cool too |
| 22:48 | <annevk> | nn |
| 23:06 | <Hixie> | should createImageDataHD() also have the imagedata argument variant? It'd be identical to the non-HD version... (/cc hober) |
| 23:07 | <Tabatkins> | For usability, I'd say yes. |
| 23:08 | <Hixie> | that's what i was thinking, but i wonder if it'll confuse people, thinking it's a way to convert a low-res imageData to a high res one or something... |
| 23:30 | hober | doesn't have a strong opinion either way |