| 00:57 | <Hixie> | AlexNRoss: did you mean "nofollow"? |
| 01:03 | <AlexNRoss> | No, I meant "dofollow". |
| 01:03 | <Hixie> | oh |
| 01:03 | <Hixie> | never heard of it |
| 01:04 | <AlexNRoss> | http://www.inlineseo.com/dofollowdiver/ |
| 01:05 | <AlexNRoss> | It encourages bots to follow the link. |
| 01:05 | <AlexNRoss> | nofollow discourages them. However, they can still go to the link. |
| 01:06 | <AlexNRoss> | It is a SEO initiative that started months ago. It's irritating that it hasn't been implemented into the spec yet; I even submitted it to the spec to be added. |
| 01:07 | <eightfold> | i'm here for the pseudo-class action |
| 01:08 | <eightfold> | a:visited:after { content: "(you've been here before)"; } |
| 01:08 | <eightfold> | should be valid? |
| 01:09 | <heycam> | jgraham, re your test, I did some similar testing recently for array index properties http://www.w3.org/mid/20110503052431.GN2576⊙wmia |
| 01:09 | <heycam> | jgraham, and I think the answer should depend on what comes out of that thread |
| 01:10 | <heycam> | the current way that named/indexed properties are handled sucks a bit |
| 01:10 | <heycam> | it's a little awkward having to look at what own properties already exist on the object, whether they're configurable or not, etc., so that they can be explicitly overwritten |
| 01:11 | <heycam> | having a [[Get]] & [[Put]] layer over the top of the object seems cleaner and easier to understand |
| 01:12 | <heycam> | I did change the spec to this "looking at what properties exist on the object and having real properties set on the object when collection elements are added" way because TC39 folks were unhappy with the custom [[Get]]/[[Put]] semantics that used to exist in the spec |
| 01:12 | <heycam> | but now they seem to be ok with it |
| 01:12 | <heycam> | (with the Proxy proposal moving forward) |
| 01:13 | <kevogod> | eightfold, Is valid code according to http://jigsaw.w3.org/css-validator/validator at least |
| 01:13 | <heycam> | jgraham, so to answer a slightly different question: what I want that test to log is true, [object HTMLImageElement], true |
| 01:14 | <Philip`> | AlexNRoss: That page says "DoFollow doesn't technically exist, instead, it is the absense of the "nofollow" tag in a link." |
| 01:14 | <Philip`> | AlexNRoss: Bots follow all links anyway (and sometimes follow things that aren't even links), there's no point explicitly marking any as followable |
| 01:15 | <AlexNRoss> | Philip`: I'm aware of this, but using "dofollow" is basically putting a big "follow this link" sign right on it. |
| 01:16 | <Philip`> | AlexNRoss: Since bots have no reason to ever care about such a sign, why put it up? |
| 01:17 | <AlexNRoss> | Philip`: It's an initiative, if people start using it, bots will use it more widely. |
| 01:17 | <Philip`> | Why would bots use it, instead of just following all links (like they do already)? |
| 01:17 | <AlexNRoss> | Philip`: https://encrypted.google.com/search?q=google+dofollow&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-CA:official&client=firefox-a |
| 01:18 | <Philip`> | That doesn't seem to be answering any questions :-p |
| 01:20 | <AlexNRoss> | Google already acknowledges it. That is what I was showing. |
| 01:20 | <AlexNRoss> | So, if it becomes official in the spec, more search engines are likely to make use of this. |
| 01:20 | <Philip`> | Where do they acknowledge it? |
| 01:20 | <AlexNRoss> | Read the search findings. |
| 01:21 | <kevogod> | ... |
| 01:21 | <AlexNRoss> | http://www.verticalmeasures.com/miscellaneous/googles-take-on-nofollow-vs-dofollow-2/ |
| 01:21 | <AlexNRoss> | Perfect example. |
| 01:22 | <Philip`> | That's just a load of people using it as a kind of pun for a phrase meaning not-nofollow |
| 01:22 | <Philip`> | i.e. for <a href> |
| 01:22 | <Philip`> | which happens to be a perfectly good way of marking up links that bots should follow |
| 01:52 | <Hixie> | AlexNRoss: nofollow doesn't actually mean "don't follow the link", it means "don't give this link any credibility" |
| 01:52 | <Hixie> | AlexNRoss: i can't find anything that suggests "dofollow" would do anything useful |
| 02:00 | <erlehmann> | nofollow is a pretty bad choice for that kind of attribute value |
| 02:01 | <Hixie> | no argument from me there |
| 02:01 | <Hixie> | heycam: btw i really think we should reconsider this foo? syntax in WebIDL |
| 02:02 | <Hixie> | heycam: having to put question marks in every IDL block is going to take me weeks |
| 02:02 | <kevogod> | Hixie, To answer eightfold's question, is a:visited:after { content: "(you've been here before)"; } valid? I do not see anything in the spec saying pseudo-elements can work with pseudo-classes. |
| 02:02 | <Hixie> | heycam: can't we do it the other way around? have an exclamation mark for the opposite case? |
| 02:02 | <Hixie> | kevogod: which spec? |
| 02:02 | <erlehmann> | kevogod, history sniffing, do you know it? i believe this will not work. |
| 02:03 | <kevogod> | Hixie, http://www.w3.org/TR/CSS2/ |
| 02:03 | <Hixie> | good lord |
| 02:03 | <Hixie> | CSS2 is over 13 years obsolete |
| 02:03 | <Hixie> | don't look at that |
| 02:03 | <erlehmann> | kevogod, i had that same trick (with a check mark :after :visited links) ruined by the history sniffing countermeasures. |
| 02:03 | <heycam> | Hixie, weeks? of course it is possible to do it the other way around for types that previously had "null" as part of them. I chose this way to avoid having both "?" and "!". |
| 02:03 | <Hixie> | kevogod: :hover::after { content: '<has hover!' } should work fine |
| 02:03 | <heycam> | Hixie, let me take a look at the html spec and determine how many "?"s would really be needed |
| 02:03 | <erlehmann> | kevogod, i believe :visited changes can only affect color. |
| 02:04 | <Hixie> | kevogod: with :link it's a bit more dodgy because of the history thing as erlehmann says |
| 02:04 | <erlehmann> | but i am too lazy looking it up. have to work on a minecraft clone. |
| 02:04 | <erlehmann> | :3 |
| 02:04 | <Hixie> | kevogod: but anyway, http://dev.w3.org/csswg/selectors3/ is where you want to go for selectors |
| 02:04 | <Hixie> | heycam: i think i would want it everywhere |
| 02:05 | <erlehmann> | kevogod, oh well. read this <http://dbaron.org/mozilla/visited-privacy>; |
| 02:05 | <heycam> | Hixie, there are really no cases where you want to throw if null is passed as an argument where an object is expected? |
| 02:05 | <Hixie> | heycam: since that's what was assumed until now, so all the prose assumes null is always allowed |
| 02:05 | <Hixie> | heycam: i'm sure there's lots of cases. but they already throw. |
| 02:05 | <heycam> | Hixie, I see |
| 02:05 | <Hixie> | i could see slowly one-by-one moving them to using IDL instead of prose to require it |
| 02:06 | <heycam> | which you could do with "!"... |
| 02:06 | <Hixie> | right |
| 02:06 | <heycam> | ok, I'll think it over :) |
| 02:06 | <dbaron> | Hixie, follow the CSS2 link, it's updated |
| 02:07 | <heycam> | Hixie, do you mind to file a bug on it? |
| 02:07 | <erlehmann> | hey, dbaron, nice job ruining our :visited selector ;D |
| 02:07 | <Hixie> | dbaron: the css2 link should point to http://www.w3.org/Style/Group/css2-src/cover.html :-P |
| 02:07 | <Hixie> | heycam: sure |
| 02:07 | <heycam> | thanks |
| 02:08 | <kevogod> | Hixie, http://dev.w3.org/csswg/selectors3/#gen-content refers to the CSS 2.1 spec so it does not necessarily clarify that ::before or :after can be applied to pseudo-classes. |
| 02:09 | <Hixie> | heycam: reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 |
| 02:10 | <heycam> | k |
| 02:10 | <Hixie> | heycam: if you do want to give me a diff (against the .../source file) then i probably wouldn't complain either |
| 02:10 | <Hixie> | heycam: (per your comment in there) |
| 02:10 | <Hixie> | heycam: you're one of hte few people i'd trust to not screw something like that up :-) |
| 02:10 | <heycam> | :) |
| 02:11 | <heycam> | if even with prose changes most types still get a "?", then changing to "!" would be better |
| 02:11 | <kevogod> | Nor do I see where it says a pseudo-element can be applied to a pseudo-class in http://dev.w3.org/csswg/selectors3/#pseudo-elements |
| 02:11 | <heycam> | so I will check that first |
| 02:11 | <Hixie> | there's 183 idl blocks in the spec |
| 02:12 | <Hixie> | kevogod: it's not applied to a pseudo-class |
| 02:12 | <Hixie> | kevogod: every selector can have one pseudo-element |
| 02:12 | <Hixie> | kevogod: and any number of combinators, pseudo-classes, normal classes, ids, attribute selectors, etc |
| 02:12 | <Hixie> | kevogod: (and one type selector per "chain") |
| 02:12 | <kevogod> | OK, that clears it up. Thanks Hixie. |
| 02:13 | <Hixie> | np |
| 02:13 | <The_8472> | too bad we can't style with xpath |
| 02:13 | Hixie | shudders |
| 02:14 | <The_8472> | think about it. absolutely position -> not in the flow -> i have to give the container some extra class/id just to give it dimensions |
| 02:14 | <The_8472> | with xpath that would go away |
| 02:15 | <The_8472> | but i guess that would be too expensive to parse |
| 02:15 | <Hixie> | how would you do it with xpath? |
| 02:15 | <The_8472> | ancestor axis |
| 02:16 | <Hixie> | oh well we can add that to selectors too |
| 02:16 | <Hixie> | that's not an xpath vs selectors thing |
| 02:16 | <Hixie> | selectors has intentionally avoided having such a feature because it's a perf nightmare |
| 02:16 | <The_8472> | i thought things are only supposed to go downwards/forwards in CSS |
| 02:16 | <Hixie> | right, i'm just saying that if that's what you're missing, it'd be easier to add it to selectors than replace selectors with xpath |
| 02:17 | <The_8472> | yeah, but that's just one example. i might want to do something with previous siblings instead... sibling axis |
| 02:17 | <Hixie> | my :matches(...#...) proposal handles all of that |
| 02:17 | <The_8472> | m'kay |
| 02:18 | <TabAtkins> | The_8472: Both of those are perfectly compatible with CSS, we've just avoided them for performance reasons, like Hixie said. |
| 02:18 | <Hixie> | a:matches(#+b) matches an a followed by a b sibling |
| 02:18 | <TabAtkins> | The downwards/forwards restriction means you can match selectors against an element *while* parsing a document, using only the information you've already parsed. |
| 02:18 | <Hixie> | a:matches(#>b) matches an a followed by a b child |
| 02:18 | <The_8472> | also, someone slap google for putting w3schools ontop of the results for anything web standard related |
| 02:18 | <The_8472> | their site is horrible |
| 02:19 | <zewt> | at least google finally added an "ignore this site forever" thing, heh |
| 02:19 | <Hixie> | The_8472: when you get a result, click it, hit back, then hit "block this site" |
| 02:19 | <zewt> | been wanting that for years |
| 02:19 | <The_8472> | mhm... but then i have to allow cookies for google |
| 02:19 | <zewt> | (now if only they'd stop fuzzing searches to death so i have to +prefix +every +word +of +every +search +to +make +it +not +add +typos +for +me) |
| 02:19 | <TabAtkins> | Google is your friend. Do what Google says. |
| 02:19 | <Hixie> | you really should log in to google anyway, it makes your results way better |
| 02:20 | <Hixie> | (disclaimer, tab and i work for google) |
| 02:20 | <kevogod> | Google tricks me into searching while logged in due to their universal log-in. |
| 02:21 | <kevogod> | :) |
| 02:26 | <The_8472> | Hixie, so... i could use that to select the previous sibling of a specific type too? |
| 02:27 | <The_8472> | ah, yeah. neat |
| 02:27 | <The_8472> | <TabAtkins> The downwards/forwards restriction means you can match selectors against an element *while* parsing a document, using only the information you've already parsed. <- just like C was designed to for a single-pass compiler. and we're all using multi-pass ones today ;) |
| 02:28 | <The_8472> | imo the runtime complexity class is more important than having to wait for the document to finish to load for (some) selectors. |
| 02:29 | <The_8472> | but it doesn't look like one can construct NP-hard statements with that ^^ |
| 02:29 | <Hixie> | it's not so much to allow single-pass (you already can't do that with e.g. :last-child) |
| 02:30 | <Hixie> | it's to allow you to style the document without having to do a full crawl of the entire document for each element |
| 02:30 | <TabAtkins> | The_8472: That's why there isn't any inherent restriction against that sort of thing. It's just not possible with currently-defined syntax, is all. |
| 02:30 | <Hixie> | consider *:matches(.foo) { }, for example, which would match any element if the document had a class=foo element in it |
| 02:30 | <Hixie> | for every element, you'd have to walk the entire document (modulo caching) |
| 02:31 | <The_8472> | well, but that is traversing the entire document once |
| 02:31 | <The_8472> | you could try to evaluate all those conditions at once |
| 02:32 | <TabAtkins> | Which isn't really a problem once the entire document is present, but it means that you can't determine if that selector matches until the entire document loads. |
| 02:32 | <Hixie> | or :matches(.foo .bar ~ .baz #) which for every element would require crawling huge parts of the dom and would be very difficult to cache efficiently |
| 02:32 | <TabAtkins> | ...Hixie, that's equivalent to just omitting :matches(). |
| 02:32 | <The_8472> | TabAtkins, that should be acceptable i think. fancy javascript stuff doesn't load either until the dom is there |
| 02:32 | <Hixie> | TabAtkins: that's not such a big problem, document load is just like dynamic changes to the dom |
| 02:32 | <TabAtkins> | The_8472: It's not acceptable. |
| 02:33 | <Hixie> | er, i had my example backwards |
| 02:33 | <Hixie> | i meant :matches(# .foo ~ .bar .baz) |
| 02:33 | <TabAtkins> | The_8472: You want to be able to display a page *as* it loads. |
| 02:33 | <TabAtkins> | And preferably as complete as possible, to minimize visual jank. |
| 02:33 | <The_8472> | so just display it based on the the forward-evaluateable rules |
| 02:34 | <The_8472> | you already have to do that, think of nth-last-child |
| 02:34 | <TabAtkins> | Those are *very* rarely used. |
| 02:34 | <TabAtkins> | And they do indeed slow the document down when you use them. |
| 02:34 | <The_8472> | should do that on a separate thread |
| 02:34 | <Hixie> | they don't slow the document down anywhere near as much as :matches() would :-) |
| 02:34 | <The_8472> | snapshot the graph and do some traversing to match the selectors |
| 02:35 | <TabAtkins> | Doesn't help. You're still doing multiple layouts over the same tree. Once a new selector is found to match, you have to throw away most of your progress over the subtree and start again. |
| 02:35 | <The_8472> | of course nobody designed/implemented dom with multithreading in mind :/ |
| 02:35 | <TabAtkins> | Because one value changing can percolate down via inheritance, etc. |
| 02:35 | <The_8472> | TabAtkins... same when JS does dynamic stuff on dom ready |
| 02:36 | <The_8472> | simple sites won't need it and complex sites will already be... complex |
| 02:36 | <The_8472> | but yes, it'll certainly not work well with naive implementations |
| 02:37 | <TabAtkins> | The problem is that people don't think of CSS as complex. We'd prefer that the performance impact be small before adding them. |
| 02:37 | <Hixie> | bbl |
| 02:37 | <TabAtkins> | s/naive/all current/ |
| 02:40 | <The_8472> | the loops that this combined with calc() might create are far more interesting |
| 02:40 | <The_8472> | mh, nvm |
| 02:41 | <The_8472> | it would just override it |
| 13:24 | <karlcow> | http://forums.silverlight.net/forums/p/230502/562113.aspx :D |
| 16:07 | <MikeSmith> | Hixie: I reverted the Overview.html copy in cvs to a version which you should be able to commit over without conflicts |
| 16:08 | <MikeSmith> | but if you do get conflicts, then, yeah, please do feel free to just blow it away and replace it |
| 16:48 | <gsnedders> | CSSOM View defines offsetTop giving the offset to the body element (in the case where there's no position properties). How do you find the offset of the body element to the viewport? (Or the offset of an arbitrary element to the viewport?) |
| 18:41 | <AryehGregor> | So Google's finally come out behind microdata instead of RDFa for search results, it seems. |
| 18:42 | <AryehGregor> | Apparently Microsoft and Yahoo! too, if they're backing schema.org, although I notice the whois goes to Google. |
| 18:43 | <AryehGregor> | (they clearly are backing schema.org, they've got blog posts announcing it too) |
| 18:44 | <AryehGregor> | http://schema.org/docs/faq.html#14 |
| 18:44 | <AryehGregor> | "Focusing on microdata was a pragmatic decision. Supporting multiple syntaxes makes documentation for webmasters more complex and introduces more overhead in terms of defining new formats. Microformats are concise and easy to understand, but they don't offer an open extensibility mechanism and the reuse of the class tag can cause conflicts with website CSS. RDFa is extensible and very expressive, but the substantial complexity of the language |
| 18:44 | <AryehGregor> | has contributed to slower adoption. Microdata is the most recent well-known standard, created along with HTML5. It strikes a balance between extensibility and simplicity, and is most suitable for building the schema.org. Google and Yahoo! have in the past supported both microformats and RDFa for certain schemas and will continue to support these syntaxes for those schemas. We will also be monitoring the web for RDFa and microformats adoption |
| 18:44 | <AryehGregor> | and if they pick up, we will look into supporting these syntaxes. Also read the section on the data model for more on RDFa." |
| 18:44 | <AryehGregor> | Ack, too long. I do that too often. |
| 18:45 | <AryehGregor> | The discussion group is also a Google Group. |
| 18:46 | <erlehmann> | AryehGregor, didn't hixie tell us that microdata was easier to author and understand than RDFa? |
| 18:47 | <erlehmann> | i wonder what CC is doing now for licensing information, i did my wordpress plugin for GSoC with RDFa. |
| 18:47 | <AryehGregor> | Well, yes, but until recently, Google's rich snippets mostly focused on RDFa, or at least as much as microdata. |
| 18:50 | <AryehGregor> | Awesome, a PAM update on Ubuntu a couple of days ago broke cron and at. How many systems will that wind up completely wrecking, I wonder? |
| 19:18 | <AryehGregor> | Hmm. |
| 19:18 | <AryehGregor> | In the execCommand() use-case, is there really any notable difference between <div align=right> and <div style="text-align: right">? |
| 19:19 | <AryehGregor> | The only obvious differences I can think of involve things like fixed-width block descendants, which you can't really get in a normal contenteditable setup. |
| 19:21 | <Ms2ger`> | Tables? |
| 19:21 | <AryehGregor> | There's no way to make those with execCommand() either, actually, that I've seen. Although you'd think there should be. |
| 19:21 | <AryehGregor> | Seems like a pretty obvious feature to add. |
| 19:23 | <AryehGregor> | I guess I'll spec it as text-align across the board for now, and change it if any problems arise. |
| 19:56 | <erlehmann> | AryehGregor, it is ubuntu. whoever runs that should know that updates break stuff, even deliberately, see unity. |
| 19:56 | <AryehGregor> | That's a major version upgrade, not a security update. |
| 19:59 | <zewt> | heh, i stopped using ubuntu after yet another major update totally hosed my system ... don't think I've ever had one go well |
| 20:14 | <Philip`> | I always mix up "microformats" and "microdata" when reading |
| 20:14 | <Philip`> | Probably would have been good if they'd had distinct prefixes |
| 20:23 | <Hixie> | "microdata" wasn't really ever intended to be a brand |
| 20:24 | <Hixie> | that one just kinda got away from me |
| 20:24 | <Hixie> | it was just meant to be descriptive, the same way that the html spec uses "microsyntax" |
| 21:44 | <linclark> | can itemprop take multiple values? |
| 22:07 | <The_8472> | mhhh... do border images support gradients instead of url() images? |
| 22:13 | <The_8472> | i guess not |
| 22:15 | <The_8472> | well, the css3 border spec and the css3 images spec contradict each other |
| 22:16 | <The_8472> | i see , they use the css2.1 definition |
| 22:26 | <Hixie> | linclark: "The itemprop attribute, if specified, must have a value that is an unordered set of unique space-separated tokens that are case-sensitive, representing the names of the name-value pairs that it adds. The attribute's value must have at least one token." |
| 22:26 | <Hixie> | linclark: in other words, "yes" |
| 22:27 | <linclark> | Hixie: thanks! |
| 23:02 | <zcorpan> | Hixie: how would you name microdata had you intended to give it a brand? |
| 23:13 | <Hixie> | zcorpan: i dunno, that's one of those things that takes careful thought |
| 23:13 | <jgraham> | Not die-rdfa-die-data then? :) |
| 23:15 | <AryehGregor> | Am I the only one who thinks it's crazy whenever people say how bad localStorage is and imply everyone should use IndexedDB instead? |
| 23:15 | <AryehGregor> | IndexedDB is *horrifyingly* complicated. |
| 23:16 | <AryehGregor> | And there's no persistent storage either implemented, specced, or planned other than IndexedDB and localStorage, that I know of (leaving aside WebSQL, since it has no future). |
| 23:17 | <Hixie> | cookies? :-) |
| 23:17 | <Hixie> | zewt: implementation complexity does matter |
| 23:17 | <AryehGregor> | Fine, no persistent storage that a) actually persists, b) does not have to be sent on every HTTP request, c) can be more than a few KB. |
| 23:18 | <zewt> | other than the annoying global lock problem, i don't think there's anything bad about localStorage; it's very natural to the platform |
| 23:18 | <AryehGregor> | zewt, it's synchronous. That's bad if you need to do a bunch of disk access. |
| 23:18 | <AryehGregor> | Because it freezes the UI. |
| 23:18 | <zewt> | well, that and the fact that everything's forever stuck at 5MB, because when you say "we'll set it at 5MB and increase it later", that apparently means "we'll set it at 5MB and then never change it" |
| 23:18 | <AryehGregor> | I don't know if that's a big problem, though. |
| 23:18 | <AryehGregor> | Yeah, but that's probably going to be true for IDB and everything else too. |
| 23:18 | <zewt> | 5MB is just patently absurd, heh |
| 23:20 | <zewt> | that can still be fixed, though, it's nothing baked in--just nobody's bothering to do so (as far as I know) |
| 23:20 | <AryehGregor> | It should really be more flexible. |
| 23:20 | <AryehGregor> | It would be better if there were no guarantees that the storage would be permanent, then you could be much more generous up front. |
| 23:21 | <AryehGregor> | There realistically aren't any guarantees that the storage is permanent anyway. |
| 23:22 | <zewt> | and there's pushback from implementors from exposing whether it is (eg. chrome's porn mode) |
| 23:22 | <zcorpan> | AryehGregor: flash cookies? |
| 23:22 | <zewt> | i don't think making it bigger but nonpersistant is much of a win, though; the entire point is persisting |
| 23:23 | <zewt> | 50MB would be a saner default than 5MB, though, really |
| 23:23 | <AryehGregor> | zewt, it only persists until the user clears cookies, or uses a different browser or whatever. |
| 23:23 | <AryehGregor> | So typical uses can't rely on it persisting anyway. |
| 23:23 | <pdr3> | Persisting? Or caching? :) |
| 23:23 | <zewt> | depends on what you mean by "persist", but yeah |
| 23:23 | <AryehGregor> | It really depends how many sites use it. |
| 23:24 | <AryehGregor> | Twenty sites all using close to the 50 MB limit would make users quite unhappy. |
| 23:24 | <Hixie> | localStorage, IndexDB, and Cookies had better all have the same lifetime |
| 23:24 | <zewt> | i really don't see every site filling up 50MB (or even 1MB) of localStorage if 50MB is given by default |
| 23:24 | <AryehGregor> | At least some users. |
| 23:24 | <AryehGregor> | Realistically, most wouldn't notice, but . . . |
| 23:24 | <Hixie> | otherwise you get cookie resurrection |
| 23:24 | <AryehGregor> | You don't need every site to do it, you just need a small percentage. |
| 23:24 | <zewt> | i mean, I get the concern of not wanting every site a user visits taking up 50MB (for example) of space, but I don't think that's a likely end result |
| 23:24 | <Hixie> | zewt: the problem isn't hte good sites |
| 23:24 | <Hixie> | zewt: the problem is the hostile sites |
| 23:24 | <AryehGregor> | Even if you visit the site only once, it will persist forever, after all. |
| 23:24 | <Hixie> | zewt: the good sites you can grant GBs of access to |
| 23:25 | <AryehGregor> | I'm not even considering DoS here. |
| 23:25 | <AryehGregor> | Just accumulation over time. |
| 23:25 | <zewt> | sure, I just don't see giving 50MB to all sites as something likely to blow up |
| 23:25 | <Hixie> | my point is the 5MB isn't intended to be used by the good sites |
| 23:25 | <Hixie> | it's just supposed to be enough to do minor stuff that isn't problematic |
| 23:25 | <Hixie> | like storing prefs |
| 23:25 | <Hixie> | if you're serious about using the site, you grant it more |
| 23:25 | <Hixie> | much more |
| 23:26 | <zewt> | that would be fine, except as far as I know implementations don't implement the "grant it more" path |
| 23:26 | <Hixie> | file bugs |
| 23:26 | <zewt> | yelling out my window feels as likely to help :) |
| 23:30 | <zewt> | is localStorage sync per spec? doesn't seem like it needs to be--would make more sense to only guarantee atomicity, and to make updates async |
| 23:31 | <AryehGregor> | Well, it's sync in the JavaScript sense. |
| 23:31 | <AryehGregor> | Just because the API is sync. |
| 23:31 | <AryehGregor> | Of course browsers don't have to do sets synchronously. |
| 23:31 | <AryehGregor> | I assume they don't. |
| 23:31 | <AryehGregor> | They probably write it and return immediately without fsync()ing. Or I'd hope they do, anyway. |
| 23:31 | <Hixie> | filing bugs does help |
| 23:32 | <AryehGregor> | But for gets, kind of hard to avoid synchronous disk reads if the API is synchronous. |
| 23:32 | <zewt> | could just read the whole thing in on the first read--which is still sync, but just once |
| 23:32 | <zewt> | (given that, even putting aside the 5MB thing, localStorage is not going to be huge) |
| 23:33 | <zewt> | my experience with filing bugs on Firefox is that I get annoying bugzilla mails for years and that's about it, heh |
| 23:33 | <zewt> | i find it amusing that when I unsubscribe from a bug because it emails me too much, it emails everyone else on the bug telling them that I unsubscribed |
| 23:35 | <Hixie> | what if there's more data stored than memory available? |
| 23:35 | <Hixie> | it only e-mails them if they opted in to getting mails about changed to the cc list |
| 23:36 | <zewt> | having that much data doesn't seem like a case for localStorage (but of course browsers can decide whether to pre-cache localStorage heuristically) |
| 23:39 | <zewt> | i guess there are also the more complex structured clone cases, like File, where you may have to cross-check mtimes or whatever--so even in 5MB, you may have thousands of File objects that would need to be verified synchronously |