| 00:00 | <gavinc> | and only store "Name On Card" |
| 00:00 | <gavinc> | Oh! |
| 00:00 | <gavinc> | That's the other value :\ |
| 00:00 | <gavinc> | Start Date for cc |
| 00:00 | <zewt> | i'd expect most things saving this stuff to be really conservative, not wanting to be liable for breaches |
| 00:01 | <gavinc> | and issue number :\ |
| 00:01 | <gavinc> | for Maestro cards |
| 00:01 | <Hixie> | gavinc: fwiw, i'm not particularly married to the idea of keeping the name on card stuff, in fact i've been trying to contact the chrome guy who did the research for chrome to see what his opinion is on dropping it |
| 00:01 | <Hixie> | haven't been able to get a hold of him yet |
| 00:01 | <Hixie> | the separated cc name fields, i mean |
| 00:02 | <Hixie> | adding these other fields seems reasonable, do lastpass and 1pass do them? |
| 00:02 | <gavinc> | yep |
| 00:02 | <zewt> | also fwiw (and also anecdotal), i can't recall ever seeing a cc form with a separated name field |
| 00:02 | <gavinc> | zewt: Hixie found one :( |
| 00:02 | <Hixie> | zewt: do a google search for "first name on credit card" or some such, it shows a bunch |
| 00:03 | <Hixie> | the original list of fields was the result of the chrome guys doing some research into what form fields were common, fwiw |
| 00:03 | <zewt> | that seems like it would fail all over the place, eg. if someone's billing name is "mr. first last" and the billing is refused if they can't enter it exactly like that |
| 00:03 | <Hixie> | it's not like they're just made up :-) |
| 00:21 | <Hixie> | ok didn't quite finish autocomplete today. still have a section to add that talks about autocomplete vs inputmode vs type |
| 00:21 | <Hixie> | bbiab. |
| 04:27 | <Hixie> | hey anyone understand this lazyblob thread well enough to give me an elevator pitch on what it's for and how it might theoretically affect websockets? |
| 04:28 | <Hixie> | (zewt maybe?) |
| 04:38 | <zewt> | the initial post is basically: some way to take a URL that you might fetch with eg. xhr (including origin, cookies, etc.), package that up and postMessage it somewhere else, so that the other side can load it |
| 04:38 | <zewt> | i don't think it has the slightest thing to do with websockets |
| 04:41 | <Hixie> | ah, ok, excellent. thanks. |
| 04:41 | <Hixie> | (interesting idea, from a technical perspective, basically a closure for a url load? what's the use case?) |
| 04:42 | <zewt> | don't recall the use cases from the OP off-hand, but i could see, for example, being able to pass a large authenticated resource (say, a movie) to another page without that page having to be given authentication info |
| 04:43 | <zewt> | (specific use cases--why you'd want to do that--i don't have handy) |
| 04:43 | <Hixie> | specific use cases seem rather important to the question of "why would we bother" :-) |
| 04:43 | <zewt> | yep, sorry, the limits of 11:45 pm :) |
| 04:44 | <Hixie> | :-) |
| 04:44 | Hixie | asks the other glenn for use cases for this websocket stuff |
| 04:44 | <Hixie> | i'm happy to let this thread rathole itself when it involves specs i haven't got the time to deal with, like xhr, but when we start threatening to give me additional work i suddenly start caring about why we're having the discussion :-P |
| 04:48 | <zewt> | and I'm going to go to bed before I accidentally click the "webapps (1)" tab and end up being up for another half hour wasting time responding to (as I can make a guess at who the (1) is) |
| 04:49 | <Hixie> | heh |
| 04:49 | <Hixie> | me, in this case, i think :-) |
| 04:49 | <zewt> | less bothersome, then :) |
| 09:10 | <hsivonen> | What's the key difference between the two aria-describedby/hidden change proposals? |
| 09:35 | __doc__ | has has his first days fill of w3c ML messages, is it always like this over there? |
| 09:40 | <jgraham> | __doc__: Depening on which list "yes" or "only when talking about a11y" |
| 09:42 | <hsivonen> | Someone should make it a policy to Formally Object to compromises to make sure that other threats of Formal Objections don't lead to compromises. |
| 09:50 | <__doc__> | hsivonen: wait, what? :) |
| 09:50 | <smaug____> | Ms2ger: eh, implementing session history defined in any spec? really? |
| 09:51 | <Ms2ger> | More likely going to be the WHATWG spec than a TR page from years back, though |
| 09:51 | <smaug____> | that is true |
| 09:51 | <smaug____> | someone from Opera was going to spec session history properly, or at least test it... I wonder what happened to that |
| 09:53 | Ms2ger | tries to remember how to declare a charset in XML |
| 09:56 | <__doc__> | Ms2ger: encoding attribute on the xml meta tag |
| 10:00 | <hsivonen> | so the Chairs decided to adopt http://www.w3.org/html/wg/wiki/FlowContentInObject |
| 10:01 | <hsivonen> | will Hixie align the WHATWG spec? |
| 10:22 | <AryehGregor> | hsivonen, do any validators care what the HTMLWG spec says? |
| 10:23 | <Ms2ger> | AryehGregor, the W3C validator, apparently |
| 10:23 | <AryehGregor> | It has its own? |
| 10:24 | <hsivonen> | AryehGregor: I'm not sure yet how much Validator.nu should care. |
| 10:26 | <hsivonen> | AryehGregor: The W3C deploys a validator built from the Validator.nu code base with W3C-specific settings. For example, the W3C instance provides an option to enable non-Lite RDFa 1.1 while Validator.nu does not. |
| 10:26 | <AryehGregor> | Ah, I see. |
| 10:29 | <MikeSmith> | AryehGregor: http://validator.w3.org/nu/ |
| 10:30 | <MikeSmith> | that is currently doing about 9.4 page validations per second, if the data from Henri's stats feature are to be believed |
| 10:30 | <MikeSmith> | or around 800,000 pages per day |
| 10:30 | <MikeSmith> | if my adding skills are to be believed |
| 10:31 | <hsivonen> | AryehGregor: I wouldn't be too surprised if the end result was making Validator.nu follow the more permissive spec on each point where the two specs disagree. |
| 10:31 | <AryehGregor> | Interesting. |
| 10:31 | <AryehGregor> | It seems fairly pointless to have two different sets of authoring conformance requirements. |
| 10:31 | <hsivonen> | AryehGregor: indeed |
| 10:31 | <AryehGregor> | But then, I don't care much about authoring conformance requirements to start with. |
| 10:33 | <MikeSmith> | hsivonen: btw, I have an little idea I've been wanting to ask you about that I hope you won't think is too radical to be worth discussing. |
| 10:33 | <MikeSmith> | the idea is, don't have the validator give any kind of binary pass/fail indicator at all |
| 10:33 | <MikeSmith> | in the validation results |
| 10:34 | <MikeSmith> | specifically, don't have it output either the "The document validates according to the specified schema(s) and to additional constraints checked by the validator." or the "There were errors." text |
| 10:34 | <hsivonen> | MikeSmith: That would indeed be radical. :-) |
| 10:35 | <MikeSmith> | in the case of the "There were errors." text, that's already clear because the errors are displayed (unless/until we add the filtering feature) |
| 10:35 | <MikeSmith> | hsivonen: I suggest it because I think way to many people get hung up on the idea of passing or failing validation |
| 10:35 | <MikeSmith> | which really is not the point |
| 10:35 | <MikeSmith> | it's a distraction |
| 10:36 | <MikeSmith> | and also because we are lying if we claim we can guarantee a document actually conforms to the spec |
| 10:36 | <hsivonen> | I guess this would be taking the "no badge" approach to the next level. |
| 10:36 | <MikeSmith> | yeah |
| 10:36 | <MikeSmith> | for one thing, we know that right now, there are a significant number of conformance constraints in the spec that we are not checking |
| 10:37 | <MikeSmith> | that will of course change over time as we implement those checks |
| 10:37 | <MikeSmith> | also there are some constraints that are not practically machine-checkable or even machine-checkable at all |
| 10:38 | <hsivonen> | The zero-message case would need some indication that the validator actually ran, though. |
| 10:38 | <MikeSmith> | of course |
| 10:38 | <MikeSmith> | yeah |
| 10:38 | <MikeSmith> | but that would be the same generic message for the no-errors case and the has-errors cases |
| 10:38 | <MikeSmith> | *case |
| 10:39 | <hsivonen> | maybe it should be the message that says which conformance definition ("HTML + SVG + MathML") was used |
| 10:40 | <MikeSmith> | ah yeah |
| 10:40 | <MikeSmith> | true |
| 10:40 | <MikeSmith> | it should say that as a minimum |
| 10:40 | <MikeSmith> | anyway, I just wanted to put a bug in your ear about it now |
| 10:40 | <hsivonen> | ok |
| 10:41 | <MikeSmith> | we can talk more about it later if you think it's actually worth exploring |
| 10:41 | <MikeSmith> | right now I got to take a break for a bit |
| 10:46 | <AryehGregor> | It should say something like "No errors found." |
| 10:48 | <AryehGregor> | Of course, there's always the question of why we want validators anyway. To tell authors about possible errors they might not know about? To pressure authors not to do things we don't like, even if it might not be worth it to them to change? To give third parties information about how much the author cares about standards? |
| 10:48 | <AryehGregor> | I have serious doubts about the usefulness of validators for any purpose other than as a lint-like tool to tell authors about possible mistkaes. |
| 10:48 | <AryehGregor> | mistakes. |
| 10:49 | <AryehGregor> | The major practical implication is that if that's all we care about, authors should be given a way to suppress arbitrary errors in case they don't care about them, as lint tools tend to permit (e.g., compiler warning flags). |
| 10:50 | <AryehGregor> | Also, if that's the primary use, there's no real reason to have anything specified formally. |
| 10:50 | <AryehGregor> | It may as well just be whatever the tool author thinks is useful. |
| 10:55 | <karlcow> | A validator tool in a publishing process (before final publication) is a bit like a compass when sailing it helps keep the route. That's the main benefit. |
| 10:56 | <AryehGregor> | In that case, it should be possible for authors to disable warnings they don't care about, perhaps with special markup in the page. |
| 10:58 | <jgraham> | I thought validation was a concept introduced by Microsoft to tie up people developing web tech in pointless arguments, thus preventing them working on useful features and allowing proprietary platforms to triumph |
| 12:21 | <MikeSmith> | AryehGregor: "lint-like tool to tell authors about possible mistakes" is much closer to what validator.nu is in practice |
| 12:21 | <MikeSmith> | than to traditional validator |
| 12:22 | <MikeSmith> | and the rules in the spec can be seen as best-practice linting rules |
| 12:22 | <MikeSmith> | with the idea that it's useful to have some standard best-practice linting rules for validators to converge on |
| 12:23 | <MikeSmith> | AryehGregor: as far as "authors should be given a way to suppress arbitrary errors in case they don't care about them", you should take a look at http://validator.keegan.st/ if you've not already |
| 12:24 | <MikeSmith> | that allows you to show/hide/filter messages as you'd like |
| 12:24 | <MikeSmith> | and the choices are persistent |
| 12:25 | <MikeSmith> | once you tell it you don't want to see a certain type/class of error, you won't see that error message for any further documents you check |
| 12:26 | <MikeSmith> | AryehGregor: details at http://keegan.st/2012/05/28/filtering-html5-validator-errors/ |
| 13:13 | <hsivonen> | java.lang.NoSuchMethodError when lauching code in Eclipse that Eclipse was happy to compile |
| 13:14 | <Ms2ger> | Heh, Java |
| 13:22 | <Stevef_> | hixie: re quoting style, point me to your preferred and I will use it (emailed you offline about it yesterday as was not near an IRC client) |
| 13:24 | <Stevef_> | Mikesmith: are there any stats for the traditional validation service? http://validator.w3.org/ i would imagine that would be doing a lot of business |
| 13:25 | <MikeSmith> | Stevef_: there probably are some stats but I've not seen them. I'll ask the systems team |
| 13:26 | <MikeSmith> | but would guess it's a few million page validations per day |
| 13:26 | <Stevef_> | mieksmith: thanks was suprised by the w3c nu markup service numbers |
| 13:26 | <MikeSmith> | yeah I was surprised too |
| 13:27 | <Stevef_> | yeah thats what i was thinking, well I have been promoting the nu service... ;-) |
| 13:37 | <hsivonen> | It turns out that I can't have GWT and HttpClient in the runtime deps at the same time |
| 13:46 | <david_carlisle> | trackbot, start telcon |
| 13:47 | <david_carlisle> | oops sorry |
| 15:04 | <jgraham> | Hmm I just realised that the tests I was writing are supposed to only work in a top level browsing context, but seem to work fine in an iframe |
| 15:06 | <jgraham> | Hixie: If I have a non-top-level browsing context why don't the steps for storing (and hence restoring) a browsing context name happen? |
| 15:15 | <Stevef_> | q+ |
| 15:16 | <MikeSmith> | Stevef_: wrong channel hombre |
| 15:20 | Stevef_ | sorry |
| 15:54 | <dglazkov> | good morning, Whatwg! |
| 15:55 | <Hixie> | jgraham: good question, didn't realise iframes could change names |
| 15:56 | <jgraham> | Hixie: Well they have a browsing context and it has a name, right? |
| 15:56 | <jgraham> | So window.name="foo" in the iframe changes that name? |
| 15:56 | <Hixie> | yeah but i always thought it as the name in the <iframe name="">, didn't think of window.name for iframes |
| 15:56 | <Hixie> | purely an oversight on my part |
| 15:56 | <jgraham> | Ah, OK :) |
| 15:56 | <jgraham> | I was just checking that I didn't miss anything important here |
| 15:57 | <Hixie> | hsivonen: the <object> decision results in allowing non-sensical markup, it was in fact a bug in HTML4 that we intentionally fixed, so no, i have no plans to adopt that proposal. (see recent meme) |
| 15:58 | <Hixie> | jgraham: send a mail or file a bug or something? (i assume it's just a matter of removing a restriction in the spec?) |
| 15:58 | <jgraham> | Hixie: Sure, I think it is just removing a few words |
| 15:59 | <Hixie> | k |
| 15:59 | <Hixie> | Stevef_: i just meant the style everyone else uses, where quotes are indented with > rather than marked with "..." |
| 16:00 | <Stevef_> | hixie: ok got it |
| 16:00 | <Hixie> | thanks |
| 16:00 | <Hixie> | (it's mentioned near the end of the whatwg faq, fwiw, including some links to software that can fix the problem in some clients like outlook) |
| 16:02 | <jgraham> | Hixie: Bug filed, but I missed my window of oppertunity for the popup so now I will have to search for it |
| 16:02 | <Hixie> | heh |
| 16:02 | <odinho> | lol |
| 16:02 | <Hixie> | 18470 |
| 16:02 | <odinho> | fix (y)our ua ;-) |
| 16:02 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18470 |
| 16:02 | <Hixie> | and thanks :-) |
| 16:05 | <jgraham> | Thanks for finding my lost and lonely bug |
| 16:22 | <Hixie> | jgraham: it was easy, it was the one at the end of the list :-) |
| 18:01 | <Hixie> | good lord, unicode updated their cldr with a boatload of new data |
| 18:01 | <ojan> | MikeSmith: I'm told you're the one to talk to about problems with the w3.org email servers...is that true? |
| 18:02 | <Ms2ger> | Good first guess, at least |
| 18:02 | <ojan> | www-style email has been getting delayed by days for me and a few others for the past couple months |
| 18:03 | <ojan> | i've already talked to gmail folk, and it looks like the problem is on the w3.org side |
| 18:46 | <Hixie> | Lachy: what's the status on the about: spec? |
| 18:47 | <Lachy> | I don't know yet. I still need to figure out if the IETF draft can be salvaged. |
| 18:48 | Ms2ger | would assume not |
| 18:48 | <Hixie> | so I should ignore the about: registry that julian talks about in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18365 ? |
| 18:48 | <Lachy> | yes |
| 18:48 | <Hixie> | roger |
| 18:48 | <Lachy> | it's quick and easy to register it though, so it won't hurt. I just wouldn't consider it essential. |
| 18:49 | <Lachy> | Tell Julian he can register the schemes if he cares that much. |
| 18:49 | <Lachy> | s/schemes/tokens/ |
| 18:49 | <Hixie> | oh, wow, that is simpler than i expected |
| 18:49 | <Hixie> | i can do those i guess |
| 18:50 | <Hixie> | any idea where i send it? |
| 18:51 | <Lachy> | yes, one sec. |
| 18:52 | <Lachy> | this form http://www.iana.org/cgi-bin/assignments.pl or send mail to iana⊙io |
| 18:52 | <Lachy> | I think that's the right address |
| 18:52 | <Hixie> | a form even! they've moved from the 80s to the 90s, i see |
| 18:52 | <Hixie> | thanks |
| 18:57 | <Lachy> | my only real problem with the registry now is that is implies some sort of exclusivity to registered tokens. Whereas about URLs should be regarded as non-resolvable addresses, which may have entirely context specific interpretations |
| 18:58 | <Lachy> | that would eliminate any possibility of conflict if two entirely independent specs happened to use the same token. |
| 19:02 | <Hixie> | ah |
| 19:13 | <Hixie> | ok i've gone through HTMLWG bugs filed up to august 1st and cloned any that looked like they were valid |
| 19:14 | <Hixie> | (who wants to bet the htmlwg never does that for the other direction yet continues to claim they care about fixing all known issue...) |
| 20:40 | <Ms2ger> | w3c: HTML WG Chairs announce editorial team for the W3C Canvas 2D Context specification http://t.co/u0FCQLpi |
| 20:46 | <jesusruiz> | hi, group! |
| 20:48 | <jesusruiz> | one question, i am writing a book and before publishing it I have to clarify one issue: |
| 20:48 | <jesusruiz> | Is it true the news that the WHATWG has separated from the W3C? |
| 20:48 | <jesusruiz> | I read on some website, which will be two html5 |
| 20:49 | smaug____ | kicks Google hard |
| 20:51 | <jgraham> | jesusruiz: The WHATWG and W3C will work on different versions of HTML, yes |
| 20:51 | <jgraham> | WHATWG will be focused on fixing bugs and adding new features |
| 20:52 | <jgraham> | W3C will be trying to keep lawyers happy |
| 20:52 | <jgraham> | By getting to Rec. which is needed for the W3C Patent Policy to kick in |
| 20:53 | <jesusruiz> | thanks jgraham |
| 20:53 | <jgraham> | That requires stability and an elaborate consensus-based decision making process |
| 20:53 | <jesusruiz> | much time working "together" for nothing, Mother of God O_o |
| 20:53 | <jgraham> | Or at least it seems to involve such an elaborate process, it isn't clear that it requires it |
| 20:55 | <jesusruiz> | :( another chaos in the web, return to the war: ( |
| 20:55 | <jgraham> | Not really chaos |
| 20:57 | <jgraham> | There is only really a problem if the UA conformance requirements are different in the two versions (other than through W3C refusing to fix a bug in version 5 in the name of stability) |
| 20:58 | <jgraham> | Author conformance requirements being differnt affects validator authors and authors that read the spec (i.e. none of them) |
| 20:58 | <jesusruiz> | good, chaos may appear, if each browser uses one or another specification. |
| 20:58 | <jesusruiz> | at least that support both specifications. |
| 20:59 | <jgraham> | It will be very surprising if browsers do differnt things; compatibility is good for the platform and so good for browser vendors |
| 20:59 | <jesusruiz> | but of course, the end is always the problem for webmasters. |
| 20:59 | <jgraham> | I expect most browser vendors to follow the WHATWG spec by necessity |
| 21:00 | <jgraham> | It will be more accurate and have more features that they need to keep up with the competition |
| 21:00 | <jesusruiz> | Yes, I agree. :) |
| 21:04 | <Hixie> | hsivonen: you around? |
| 21:06 | <jesusruiz> | Hixie: save the web! ;) |
| 21:07 | <jesusruiz> | W3C bad! :) |
| 21:07 | <Hixie> | not up to me, it's up to the vendors :-) |
| 21:07 | <Hixie> | MikeSmith: yt? |
| 22:29 | <Hixie> | hober: is image-set() going anywhere? |
| 22:30 | <hober> | Hixie: TabAtkins keeps saying he'll add it to CSS4 Images, but I don't know when he'll get to it. |
| 22:31 | <Hixie> | is it basically the same as srcset="" is now? |
| 22:31 | <Hixie> | but with cssy syntax? |
| 22:31 | <hober> | AFAIK it only handles the resolution case |
| 22:32 | <hober> | but that will depend on whatver TabAtkins puts in the draft |
| 22:32 | <Hixie> | ah ok |
| 22:32 | <hober> | as currently implemented, -webkit-image-set() only supports the resolution case, fwiw |
| 22:33 | <Hixie> | right |
| 22:33 | <hober> | on the css side of things, the art direction case is probably best handled with the existing mechanisms (MQs etc0 |
| 22:34 | <Hixie> | yeah |
| 22:35 | <hober> | i think the only change i remember TabAtkins planning to make was to add the ability to specify a <color> |
| 22:36 | <hober> | (if the ua decides that *none* of the resources are to its liking, it could display the color instead) |
| 22:36 | <Hixie> | interesting |
| 22:41 | <zewt> | hober: or image-set(url(...), url(...), rgba(...))? |
| 22:43 | <Hixie> | more like image-set(url(...) 1x, url(...) 2x, rgba(...)) or some such, right? |
| 22:46 | <TabAtkins> | hober: I've already got it started, I just need to finish writing it out. Expect it to show up this evening or tomorrow. |
| 22:46 | <TabAtkins> | Would have done it Tuesday, but was working on Flexbox and sizing things with fantasai instead. |
| 22:47 | <TabAtkins> | But yeah, planning on only doing the resolution stuff, because MQ does the other parts fine. |
| 22:47 | <zewt> | Hixie: yeah, I just mean that support for a color shouldn't be a special case |
| 22:47 | <TabAtkins> | <img srcset> just doesn't have an easy way to do MQs, so it has to reinvent them in its syntax. |
| 22:47 | <Hixie> | zewt: it's still special :-) |
| 22:47 | <zewt> | (note: i know nothing about image-set aside from the last page or so of IRC) |
| 22:48 | <TabAtkins> | hober: I'm still not sure what to do about 2x vs <resolution> |
| 22:48 | <Hixie> | TabAtkins: yeah |
| 22:48 | <Hixie> | it's amazing how HTML's syntax is constraining us |
| 22:48 | <Hixie> | but anyway |
| 22:48 | <hober> | TabAtkins: drop <resolution> obviously :) |
| 22:48 | <Hixie> | hober++ |
| 22:48 | <othermaciej> | <resolution> is lame |
| 22:48 | <othermaciej> | no one will remember or understand what dppx units mean |
| 22:48 | <TabAtkins> | The "x" unit is just a synonym for "dppx". |
| 22:49 | <TabAtkins> | I'd prefer to just make it an explicit synonym. |
| 22:49 | <othermaciej> | and I think specifying dpi for this use case is not valuable |
| 22:49 | <TabAtkins> | ...you're already specifying dpi. |
| 22:49 | <hober> | dp{i,cm,px} should just go away entirely; they're crazy |
| 22:50 | <othermaciej> | no, you're specifying a scale factor relative to "normal" |
| 22:50 | <TabAtkins> | Normal is 96dpi. |
| 22:50 | <othermaciej> | but there's no good reason to say 192dpi instead of 2x |
| 22:50 | <othermaciej> | and it may make you think you can say things like 200dpi, which will get you ugly blurry output |
| 22:51 | <TabAtkins> | It's probably less useful in this case, yeah. But you're still specifying a resolution, so it's weird if you can't use the other resolution types. |
| 22:51 | <othermaciej> | or worse yet, it may make you think you should use the actual physical device dpi, which in this case would be utterly wrong |
| 22:51 | <hober> | but no one should ever, ever use the otheer resolution types |
| 22:51 | <hober> | s/ otheer// even :) |
| 22:52 | <othermaciej> | you might think you should say 326dpi instead of 192dpi |
| 22:52 | <hober> | exactly |
| 22:52 | <othermaciej> | for the iphone |
| 22:52 | <othermaciej> | css overloading dpi to mean something unrelated to physical dpi is a bad idea |
| 22:52 | <othermaciej> | and should not be propagated |
| 22:54 | <othermaciej> | 192dpi is closer to the actual physical dpi of the original iPhone than to the Retina iPhone |
| 22:54 | <Hixie> | note that the display resolution is not necessarily just 1x vs 2x; consider browser zoom, or the retina macbook pro resolution setting |
| 22:55 | <hober> | right. image-set(foo 1x, bar 2x) just means that bar's resolution is twice that of foo's; it doesn't make any claims to foo or bar's actual resolution. the ua can then pick whichever would be best in the current circumstance |
| 22:55 | <othermaciej> | sure, you could have fractional zoom |
| 22:55 | <othermaciej> | but describing in in terms of dpi just confuses the issue |
| 22:55 | <TabAtkins> | hober: Well, that's no good. That means you can't ever rely on auto sizing. |
| 22:56 | <TabAtkins> | "2x" needs to very strictly mean "this is 192dpi". |
| 22:56 | <hober> | auto sizing works fine |
| 22:56 | <othermaciej> | it doesn't mean "this is 192dpi", it means, "choose this when 2x scale is appropriate and downscale it by 2" |
| 22:56 | <Hixie> | othermaciej: 100% agree on dpi being pointlessly confusing here |
| 22:56 | <hober> | what othermaciej said |
| 22:56 | <Hixie> | like setting font-size in pt or width in cm |
| 22:56 | <TabAtkins> | Those two statements are equivalent. |
| 22:57 | <othermaciej> | no, because dpi could be taken as a statement about the image's intended true physical resolution |
| 22:57 | <TabAtkins> | Because the 1x scale means "this is 96dpi". |
| 22:57 | <hober> | no it doesn't |
| 22:57 | <othermaciej> | except to people who know the insane CSS definition of DPI |
| 22:57 | <TabAtkins> | You can *think* your iamge is something else, but you're wrong. It's 96dpi by definition. ^_^ |
| 22:57 | <othermaciej> | (and believe it) |
| 22:57 | <TabAtkins> | Hixie: You coming to my desk? |
| 22:57 | <othermaciej> | it's 96 dots per CSS inch, not 96 dots per inch |
| 22:58 | <othermaciej> | a normal person would not think that "dpi" means "multiply by 96" |
| 22:58 | <othermaciej> | so calling that unit dpi is bordering on evil |
| 22:58 | <othermaciej> | furthermore, there is no particular case where it is helpful or convenient to multiply by 96 |
| 22:59 | <TabAtkins> | What are you talking about? There's no multiplication by 96. |
| 22:59 | <othermaciej> | and it makes it harder to see which values represent an integral scale factor |
| 22:59 | <TabAtkins> | "dots per CSS inch" is approximately the same as "dots per physical inch", and the approximation gets closer as resolutions go up. |
| 22:59 | <othermaciej> | it is in no way approximately the same |
| 23:00 | <othermaciej> | the iPhone has 192 dots per css inch and 326 dots per physical inch |
| 23:00 | <TabAtkins> | At a normal zoom factor it is. |
| 23:00 | <othermaciej> | 192 is not approximately the same as 326 |
| 23:02 | <hober> | If I've done the math right, I think 1 CSS liter is 37,795 cubic pixels. |
| 23:03 | <othermaciej> | CSS liter makes about as much sense as CSS dpi :-) |
| 23:03 | <hober> | (cubic css pixels, of course.) |
| 23:03 | <hober> | yeah, exactly |
| 23:14 | <zewt> | cool, that thread is now totally derailed |
| 23:14 | <zewt> | (ugh) |
| 23:15 | <hober> | zewt: the lazy blob thread? |
| 23:15 | <zewt> | yeah |