| 01:29 | <Hixie> | <script src="/static/affiliate_base/js/base.js"> anyone? |
| 01:30 | <Hixie> | or <script src="/j-east/js/form.js"> ? |
| 01:32 | <Lachy> | Hixie, base.js could be Dean Edward's base.js script |
| 01:32 | <kingryan> | Hixie: I take it that your test environment doesn't give you access to the url of the markup source? |
| 01:32 | <kingryan> | Lachy: I doubt it, given the 'affiliate_base' |
| 01:32 | <Hixie> | lachy: i found a version with that path here: http://www.booking.com/static/affiliate_base/js/base.js -- my working assumption right now is that it's a booking.com-specific script |
| 01:33 | <Lachy> | ok |
| 01:33 | <Lachy> | Hixie, what's your purpose in looking at all of these scripts? |
| 01:33 | <Hixie> | kingryan: sadly, no, one of the problems with scanning billions of documents is that you have to throw out a lot of data lest you just output terabytes and terabytes of data |
| 01:34 | <kingryan> | but google has terabytes of storeage to spare, right? :) |
| 01:34 | <Hixie> | Lachy: twofold; trying to see what libraries are out there and widely used, and trying to see what things are commonly done to get an idea of where we need to work on in the future to make APIs better |
| 01:34 | Lachy | believes Google has infinite storage :-) |
| 01:35 | <Hixie> | it's not quite that easy :-) |
| 01:39 | <Hixie> | woot, found one j-east/js/form.js: http://sciencelinks.jp/j-east/js/form.js |
| 09:43 | <hsivonen> | hmm. 66 messages in the www-style @ua thread... |
| 09:47 | <Lachy> | hsivonen, was that thread just rehashing all the arguments for adding browser sniffing to css? |
| 09:47 | <Lachy> | I didn't bother reading it, since it didn't seem like anything new |
| 09:48 | <hsivonen> | Lachy: yes, but I haven't read it properly. |
| 09:49 | <othermaciej> | browser sniffing sucks, but not having it also sucks |
| 09:50 | <zcorpan> | hsivonen: is there something interesting going on in www-style? i'm not subscribed |
| 09:50 | <Lachy> | zcorpan, not much |
| 09:50 | <zcorpan> | Lachy: ok |
| 09:51 | <othermaciej> | dbaron's review of hyatt's CSS transforms / animations proposal was interesting |
| 09:51 | <Lfe> | othermaciej: url? |
| 09:52 | <othermaciej> | Lfe: http://lists.w3.org/Archives/Public/www-style/2007Nov/0223.html |
| 09:52 | <Lfe> | othermaciej: thanks! |
| 09:52 | <othermaciej> | (see thread for original proposal) |
| 09:52 | <othermaciej> | I have a neat demo of that stuff which I should post |
| 09:53 | <Lfe> | That i've read, havent followed the discussion though. |
| 09:53 | <hsivonen> | zcorpan: the most interesting things in general are the Apple proposals othermaciej mentioned. (personally, I should follow up to some of the media query validation issues) |
| 09:53 | <zcorpan> | hsivonen: k |
| 12:58 | <hsivonen> | oh great. the data URI ;base64 doesn't appear to allow white space between ; and b |
| 12:58 | <hsivonen> | yay for consistent parsing |
| 13:18 | <OmegaJunior> | Are we forcing compliant browsers to accept data URIs? That'd be a first for MSIE. |
| 13:27 | <hsivonen> | OmegaJunior: I expect not |
| 13:28 | <OmegaJunior> | Ah, too bad. |
| 13:34 | <hsivonen> | does anyone remember if Python urllib2 requests gzip compression? |
| 13:35 | <OmegaJunior> | Sorry no, never worked with it. |
| 13:36 | <hsivonen> | apparently, no |
| 13:36 | <hsivonen> | :-( |
| 16:10 | <zcorpan> | oh. firefox doesn't ignore the mime type with xml-stylesheet |
| 16:10 | <zcorpan> | (but everyone else does) |
| 16:11 | zcorpan | changes the spec to make xml-stylesheet honor mime type |
| 16:15 | zcorpan | also finds that safari supports "inline" stylesheets á la <?xml-stylesheet href="#a"?><p xmlns="http://www.w3.org/1999/xhtml"; id="a">p { background:yellow }</p> |
| 16:16 | <zcorpan> | s/á/à/ |
| 16:16 | <zcorpan> | wonder if i should require that to work |
| 16:23 | <gsnedders> | zcorpan: what about xml:id? |
| 16:25 | <zcorpan> | nope |
| 16:25 | <zcorpan> | seems webkit doesn't support xml:id at all |
| 18:08 | <zcorpan> | http://simon.html5.org/specs/xml-stylesheet5 now features entities |
| 18:09 | <anne-mac> | I don't think we should add the stuff btw that only WebKit supports |
| 18:09 | <anne-mac> | The additional complexity has no real use case as far as I can tell |
| 18:10 | <zcorpan> | ok |
| 18:11 | <gsnedders> | I expect from the face of it that it's just due to how it is implemented and not intentional |
| 18:11 | <anne-mac> | The entity stuff doesn't handle EOF |
| 18:11 | <zcorpan> | EOF will be part of the entity table lookup |
| 18:12 | <zcorpan> | no? |
| 18:12 | <zcorpan> | gsnedders: don't think so |
| 18:12 | <anne-mac> | it's not at all clear what should happen when you hit a parse error |
| 18:13 | <zcorpan> | doesn't really matter |
| 18:13 | <anne-mac> | besides marking the pseudo-attribute as being in error |
| 18:13 | <zcorpan> | the pseudo-attribute will be dropped later on |
| 18:13 | <zcorpan> | so what the value is doesn't matter |
| 18:14 | <zcorpan> | but the number of consumed characters matters if you've consumed a " or ' |
| 18:15 | <anne-mac> | you can't consume those per the current algorithm, so I guess you're correct |
| 18:15 | <zcorpan> | i guess i could deal with ', " and EOF up front to make the spec clearer? |
| 18:15 | <zcorpan> | right |
| 18:16 | <anne-mac> | "Otherwise, if the next character is a U+003B SEMICOLON, consume that too." is slightly confusing as it doesn't directly follow from the if statement before |
| 18:16 | <zcorpan> | also applies to html5, in that case :) |
| 18:16 | zcorpan | ripped most off |
| 18:17 | <anne-mac> | XSLT processing rules is inside <code> |
| 18:18 | <zcorpan> | oops |
| 18:18 | <anne-mac> | "(i.e., had the MIME type text/css)" seems also wrong given the statement before it |
| 18:19 | <anne-mac> | (i.e., had the MIME type text/plain instead of text/css) would be better |
| 18:19 | <anne-mac> | the DOM3Views reference should be DOM2Views |
| 18:20 | <anne-mac> | and Acknowledgements should be spelled Acknowledgments per en-US |
| 18:23 | <zcorpan> | fixed. thanks |
| 18:25 | <zcorpan> | it seems that implementations treat  as a parse error. but i'm not sure it's that important. and other values aren't interoperable, like ffff or 110000 |
| 18:26 | <zcorpan> | so i just aligned with html5 |
| 18:27 | <anne-mac> | html5 will change methinks |
| 18:27 | <zcorpan> | to what? |
| 18:27 | <anne-mac> | not sure, surrogate characters will have to be dealt with somehow, at least |
| 18:28 | <zcorpan> | oh yep |
| 18:29 | <anne-mac> | "(in other words, 0-9, A-F, a-f)" is not in the same order as the stuff before it and misses "and" |
| 18:31 | <zcorpan> | fixed. also in html5 |
| 18:32 | <zcorpan> | a surrogate is not a parse error in firefox |
| 18:33 | <zcorpan> | though i think i'll leave it for now |
| 18:37 | <zcorpan> | a fun feature (not in the spec currently) is that you can point to the file itself and let it act as a style sheet |
| 18:38 | <zcorpan> | since <!-- is a valid css token you can have your style rules in a comment in the prolog |
| 18:39 | <anne-mac> | that's more or less disabled by doing media type checking |
| 18:39 | <zcorpan> | indeed |
| 18:40 | <zcorpan> | but it works in webkit and ie |
| 18:41 | <zcorpan> | http://simon.html5.org/test/xml/xml-stylesheet/css/019.xml |
| 18:42 | <csarven> | thats cool |
| 18:43 | <anne-mac> | also works in Opera |
| 18:43 | <zcorpan> | ah yep. though not in 9.2x it seems |
| 18:44 | anne-mac | is playing with Opera 9.5 Beta on MacOS X |
| 18:44 | <anne-mac> | 9.50, even |
| 18:58 | <anne-mac> | btw, if Content-Type is honered you don't have to default to CSS anymore in theory |
| 18:59 | <zcorpan> | it's only honored after type="" has had it's say |
| 18:59 | <anne-mac> | that's how it currently works in Firefox? |
| 18:59 | <zcorpan> | 1) type="" decides if you're gonna do css processing, xslt processing, or ignore the PI altogether |
| 19:00 | <zcorpan> | 2) the mime type decides if you're gonna apply the resource at all |
| 19:00 | <zcorpan> | yeah |
| 19:00 | <anne-mac> | in that case 2) seems like a needless step |
| 19:01 | <zcorpan> | yeah, but people don't like it when content-type is ignored |
| 19:03 | <anne-mac> | hmm |
| 19:30 | <zcorpan> | one thing i wonder. should it be possible to insert a ProcessingInstruction node to the DOM in html? |
| 19:31 | <zcorpan> | dom core says no, and firefox and webkit don't allow it |
| 19:31 | <zcorpan> | but i don't see a good reason for it |
| 19:32 | <zcorpan> | or well, i know the reason; that implementations at the time didn't support it declaratively in html |
| 19:33 | <zcorpan> | but doing different things in the dom based on the htmlness flag sucks |
| 19:33 | <zcorpan> | anyway. gotta go |
| 20:05 | <hendry> | hsivonen: don't quite get this transparent error message on http://validator.nu/?doc=http%3A%2F%2Fvideo.natalian.org%2F |
| 21:07 | <Hixie> | wow |
| 21:07 | <Hixie> | what an interesting precedent was just set |
| 21:07 | <Hixie> | i look forward to making arbitrary decisions and invoking the secret opinions of anonymous contributors to back me up |
| 21:09 | <Philip`> | Like the 10% of emails in your issues list that are private? |
| 21:11 | <Hixie> | they're only private because they were sent directly to me (or to a nonpublic list like mozilla-security), if someone said something that disagreed with an e-mail in that list i couldn't let the anonymous hidden mail override the other feedback |
| 21:11 | <Hixie> | there has to be some accountability |
| 21:31 | <gsnedders> | Hixie: what precedent? where? |
| 21:32 | <hober> | gsnedders: see danc&maciej's exchange, cc'ed to www-archive |