Алексей Капранов: Повествовательный формат для веб-форм | Fresh: новости мира юзабилити
|
Повествовательный формат для веб-форм | Fresh: новости мира юзабилити - http://fresh.gui.ru/2010...
|
|
Повествовательный формат для веб-форм | Fresh: новости мира юзабилити - http://fresh.gui.ru/2010...
|
|
Компания Microsoft, как было обещано ранее, открыла спецификации, связанные с бинарным форматом ".pst" (Personal Storage Table), используемом для хранения данных Outlook, включая архив переписки, список контактов и события из календаря-планировщика. Документация отнесена к категории открытых спецификаций, что подразумевает официальное разрешение... - http://www.opennet.ru/opennew...
|
Yesterday evening I returned from my fourth foreign trip this year. This time I went to the Mobile World Congress, the annual Barcelona-based get-together of the mobile industry, and I can tell you, it’s something else.
This post gives an overview of announcements by mobile players that might be of interest to web developers. There’s an incredible lot of it, too, because every single major mobile player except Apple feels that MWC is the ultimate forum for major announcements.
If you know of more news, or have links to additional information, please leave a comment.
I was there because Vodafone had invited me to sit on a
panel in a technical “embedded
conference” about W3C Widgets and related technologies.
The concept can use some fine-tuning; I’m hoping to do some of that in the future.
I was there mainly to stress that the mobile browser situation is not as simple as it looks. THERE
IS NO WEBKIT ON MOBILE!
While I was at it I also invented guerilla browser testing.
lightweight, robust mechanism for digitally signing nearly arbitrary messages, along with a basic public key infrastructure for discovering the signing keys
|
Envisioning decentralized @replies and notifications with WebFinger. - http://www.google.com/buzz...
|
application:
import logging
logging.warn('WSGI sends to the Apache2 error_log.')
settings.py:
import sys
import logging
logger = logging.getLogger('')
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler(sys.stderr)
handler.setLevel(logging.DEBUG)
formatter = logging.Formatter('[%(asctime)s - %(levelname)s - %(filename)s:%(lineno)d] %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
в свете недавнего подключения гуглом поддержки webfinger для всех публичных профилей я решил сделать то же самое для своего емейла me@arty.name. Как выяснилось, это очень просто.
.well-knownhost-meta, me@arty.name, acct:me@arty.name, .htaccessв файле host-meta я написал:
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:hm='http://host-meta.net/xrd/1.0'>
<hm:Host>arty.name</hm:Host>
<Link rel='lrdd'
template='http://arty.name/.well-known/{uri}'>
<Title>Resource Descriptor</Title>
</Link>
</XRD>
в файлах me@arty.name и acct:me@arty.name я написал:
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
<Subject>acct:me@arty.name</Subject>
<Alias>http://arty.name/</Alias>
<Link rel="http://webfinger.net/rel/profile-page"
href="http://arty.name/" type="text/html"/>
<Link rel="http://microformats.org/profile/hcard"
href="http://arty.name/" type="text/html"/>
<Link rel="http://gmpg.org/xfn/11"
href="http://arty.name/" type="text/html"/>
<Link rel="http://specs.openid.net/auth/2.0/provider"
href="http://arty.name/"/>
<Link rel="describedby" href="http://arty.name/"
type="text/html"/>
</XRD>
для того, чтобы все эти файлы отдавались с правильным Content-Type, в .htaccess я добавил строчку
DefaultType application/xrd+xml
вуаля! теперь можно идти на webfinger demo client и пробовать там адрес me@arty.name
что касается двух одинаковых файлов: нынешний черновик спецификации webfinger предполагает, что URI будет начинаться с acct:. Однако демо-клиент, видимо, был написан ещё до этого решения, и не только не добавляет эту схему к емейлам, но даже удаляет её, если она указана явно.
Monospace text sizing is, from time to time, completely unintuitive and can be quite maddening if you don’t look at it in exactly the right way. Fortunately, there is a pretty simple workaround, and it’s one you might want to consider using even if you weren’t aware that a problem existed.
But first, allow me to lay some foundations. Assuming no other author styles beyond the ones shown, consider the following:
span {font-family: monospace;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
All right, what should be the computed font-size of the span element? Remember, there are no other author styles being applied.
The savvier among you will have said: “It depends, but most likely 13px.” That’s because here, the size of the monospace text is controlled by the browser’s preferences. The vast majority of users, of course, have never touched their default settings of “16″ for proportional fonts and “13″ for monospace/fixed fonts. For them, then, the answer is 13px. Similarly, if I’d asked about the p element’s computed font-size, the answer would be: “It depends, but most likely 16px.”
So let’s add a bit more and see where we land.
span {font-family: monospace; font-size: 1em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
As before: bearing in mind that there are no other author styles, what should be the computed font-size of the span element?
In this case, building on the previous question and answer, you might say, “It depends, but most likely 16px.” The reasoning here is pretty straightforward: since the computed font-size of the p element is 16px, the font-size: 1em; assigned to the span will result in it having the same size.
And that’s true… in two of five browsers I tested: Opera 10 and Internet Explorer 8. In the other three I tested—Firefox 3.6, Safari 4, and Chrome 4—the computed (and rendered) font-size of the span is 13px, the same as in our first example. This result holds true if the rule is changed to use font: 1em monospace; instead of the two separate properties. The behavior continues to persist even when adding specific font families, like Courier New, Courier, Andale Mono, and so on to the rule. It also persists if 1em is converted to 100%.
So in other words, even though I have written CSS that explicitly says “Make the font-size of this element the same as its parent”, three of five browsers apparently ignore me.
I say “apparently” because what’s happening is that those browsers are allowing the span to inherit the default font-size from its parent (and thus, indirectly, all its ancestors), but the default font-size is medium. If you go look up medium, you find out that it doesn’t have a defined numeric size. So what those browsers do is equate medium with the preference settings, which means it’s different for monospace fonts than for everything else.
In other words, those three browsers are doing something like this:
span needs to have the same font-size as its parent element.font-size is medium, even though when my web inspector (or an author’s DOM script) asks, I report the 16px I used to output the text. So the span’s font-size is actually medium.medium-sized span is using a monospace font. The preference setting for monospace is “13″, and I equate medium with the preference setting, so I’ll output the span using 13-pixel text.Opera 10, as I said, doesn’t do this, even if your monospace font preference setting is the default value of “13″ or indeed different from the preference for non-monospace fonts. And IE8 doesn’t appear to do it either, although you can’t set numeric font size preferences in IE8 so what it’s actually doing is open to interpretation. Oh, IE8, you inscrutable little scamp, you.
All that might seem reasonable enough, but it turns out that’s not the whole story. No, the three resizing browsers are being a good deal more “clever”, if that’s actually the word I want, than that. In fact, what those browsers do makes it seem like they use the two preference settings to create a ratio, and that ratio is used to scale monospace text. That’s not actually what’s happening, but it looks that way at first. To see what I mean, let’s consider:
span {font-family: monospace; font-size: 2em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
Again: in the absence of other author styles, what should be the computed font-size of the span element?
The answer: “It depends, but most likely 26px as long as we aren’t talking about Opera 10 or IE8. If it is one of those two, then most likely 32px.” Why? Because the resizing browsers see the font-size: 2em; declaration as “twice medium” and twice 13 is 26. Opera 10 and IE8, as previously established, don’t do the resizing. Or else they simply interpret medium as being equal to the proportional font size preference setting. Whatever.
Okay. So what all this means is that in many browsers, you can declare that an element’s font size should be twice the size of its parent’s and have it actually be 1.625 times the size—or, if you want to look at it another way, 0.8125 times the size you expected it to be. The 0.8125 comes from 26/32, which of course reduces to 13/16. If you were to adjust your browser’s preferences so the monospace setting is “15″, then monospace fonts would be 0.9375 (15/16) times the expected size.
But—and here’s where things get really fun—this is not always so. See, you may not have run into this problem if you’ve been declaring specific font families with no generic fallback. Consider this variation (note that I dropped back to 1em for the font-size):
span {font-family: "Courier New"; font-size: 1em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
This time, in every one of the five browsers I mentioned before, assuming the browser defaults, the computed (and rendered) font-size of the span will be 16px. Not 13px. And the only difference is that we switched from a generic font family to a specific one.
“Hey presto!” you shout. “We’ll just tack the generic family on the end there and be right as rain!” Sadly, no. For if you do this:
span {font-family: "Courier New", monospace; font-size: 1em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
…then the answer to the question I keep asking will be: “It depends, but given browser defaults it will be 16px, unless we’re talking about Safari. In that case, it’s 13px.”
Really. Alone among the browsers I tested, Safari goes back to doing the resizing when you provide a generic fallback to your specific family. Or even multiple families. Do your best to make sure the user at least gets a fixed-width font, and you get a size smaller than you’d intended. (You can get the back story on this in a late-2006 post on the Surfin’ Safari blog.)
So what do we do? Get creative. That’s what the ARIA folks did in their specification’s style sheet, where they declare two font stacks: the first with a generic fallback, and the second without it. That works, but it’s ugly. I didn’t like that at all. And then, halfway through writing up this post, a fix came to me like a shot in the dark. Check this out:
span {font-family: "Courier New", monospace, serif; font-size: 1em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
This time around, the answer is: “It depends, but given browser defaults, 16px.”
Really! Even in Safari! And in all tested browsers, it falls back to a generic monospace font at the requested size even if the specific family (or families) we declare aren’t available! This can be verified by altering the specific font family to something that doesn’t actually exist:
span {font-family: "Corier Neu", monospace, serif; font-size: 1em;}
<p>This is a 'p' with a <span>'span'</span> inside.</p>
Monospacey goodness at the intended, parent-matching size. It’s enough to make a body believe in monotheism.
Since I generally assume that anything I devise was already invented by someone else, I went Googling for prior art. And wouldn’t you know it, the Wikipedia folks had worked it out around the end of last year. This, of course, supports my contention that Wikipedia is the new Steve Allen. I also found some claims that ending the font stack with monospace, monospace would have the same effect, but that wasn’t borne out in my testing. Perhaps it worked in older versions of browsers but no longer does.
I did leave out another way to make monospaced fonts behave as expected, which you may have already figured out from the preceding: declare the font-size for any parent of a monospaced element to be a length value, along the lines of body {font-size: 12px;}. That will pass the length value down the document tree to the monospaced element via inheritance, which will use it without resizing it in every browser I tested. Though you may have heard that page zooming makes pixel-sized text okay, I’m not really convinced. Not yet. There are too many people who don’t know how to zoom, and too many whose browsers aren’t advanced enough to zoom pages. Even in page-zooming browsers, there are problems with pixel text. So I’m still on the ems-and-percentages bandwagon.
In fact, there are a fair number of details and extra browser oddities that I left out of this, as it’s already way more than long enough, and besides you don’t really want to hear the gory details of manually stepping through 37 different preferences settings just to verify a theory. Plus you already heard about the font-size rounding investigation that spawned off of this one, about halfway through. I think that’s more than enough for the time being.
I should also lay down a caveat: it’s possible that this behavior will be interpreted as a bug by the Safari team and “fixed”, if that’s the word I want, in a future release. I really hope not—and if they’re looking for ways to improve how they handle monospace font sizing, I have a few suggestions—but it is possible. Adjust your expectations accordingly.
And with that, I’m going to stop now. I hope this will be useful to you, either now or in the future.
Plupload (via). Fantastic new open source project from the team behind TinyMCE. Plupload offers a cross-browser JavaScript File uploading API that handles multiple file uploads, client-side progress meters, type filtering and even client-side image resizing and drag-and-drop from the desktop. It achieves all of this by providing backends for Flash, Silverlight, Google Gears, HTML5 and Browserplus and picking the most capable available option.
Shared by arty
любопытно, что при этом из комментариев обоих конкурентов следует, что они сделали закрытый сервис для избранных партнёров
Конкуренты считают, что Google тормозит: в Microsoft интеграция социальных сервисов с Hotmail сделана ещё в 2008 году, а Yahoo напомнил о своем сервисе Yahoo Updates, работающем в течение года.
Since my attempts at capturing web developers’ hearts and minds by publishing fundamental research have failed miserably but my thirst for attention continues unabated, today I will once more shout at iPhone developers. That’s proven to work.
More specifically, today I will shout at web developers who think that delicately inserting an iPhone up their ass is the same as mobile web development.
Before we start, a little thought experiment. Suppose I proposed the following:
Would you agree with those sentiments, even if we’re back in 2000 and IE6 is really the best browser we have?
Or would you reply that our sites should work as well as they can in all browsers through the use of web standards, progressive enhancement, and all the rest of the best practices we’ve been preaching for the past ten years?
I distinctly remember a time when we web developers cared about such concepts. But those times are long gone.
|
HOWTO Use Python in the web - http://docs.python.org/howto...
|
dogproxy. Умная прокся для реально stateless запросов: если на один ресурс одновременно приходит много обращений, то он считывается один раз и раздаётся всем желающим. Может быть удобным, например, при долгой перегенерации минимизированных js/css. Интересно было бы сравнить эффективность с дисковым кешем OS.
|
an HTML5 offline image editor and uploader application - http://demos.hacks.mozilla.org/openweb...
|
I would also like to mention that while our Licenses are not concluded by End Users, anyone in the product chain has liability if an end product is unlicensed. Therefore, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the End User, but where a royalty has not been paid, such a product remains unlicensed and any downstream users/distributors would have liability.Конец цитаты.
Примечание об источниках: это письмо было целиком опубликовано вон там, а попал я туда по гиперссылке из обсуждения на LORе.Вот веский, вот настоящий повод перейти на Theora всем миром.
Plurk: Instant conversations using Comet (via). Plurk’s comet implementation sounds pretty amazing. They’re using a single quad-core server with 32GB of RAM running 8 Node.js instances to serve long-polled comet to 100,000+ simultaneous users. They switched to Node from Java JBoss/Netty and found the new solution used 10 times less memory.