Re: [whatwg] Proposal for non-modal versions of modal prompts
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version of window.confirm() or window.alert(). Dialogs that are fully
in-page
Oops, got cut off here. What I meant to say is something like dialogs
that are fully in-page are the emerging standard for high-quality
page-modal prompting.
Non-blocking window.{alert,confirm,prompt} would most likely be rendered by
UAs as in-page overlays / tab-scoped dialogs. This is what we would do in
Chrome, and it seems like others would do the same given the prevalence of
the standard window.{alert,confirm,prompt} being implemented in a
tab-scoped manner already by some browsers (albeit with bugs).
I think people use alert, confirm and prompt in part because they are so
easy to use. People who choose window.{alert,confirm,prompt} probably
don't care about loss of customization or else they would roll their own
dialogs.
Why not provide less sucky versions of those common dialogs?
Benefit: Less code for simple dialogs.
Con: Another web platform API to standardize.
-Darin
I should add that this could be partly for path-dependent reasons, and
that if other technologies had been available, authors might not have
resorted to in-page modality with overlays. But I think the key missing
enabled was not asynchrony but rather the ability to fully control the UI,
layout and available commands of the modal experience.
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production debugging aid. In both cases, authors
who care about the user experience will use dialog or a JS-implemented
lightbox style dialog. And authors who do not care about user experience,
or who are doing a quick debugging hack in non-production code, will use
old-fashioned blocking alert/confirm/prompt. Thus, I am not sure there is
really a meaningful audience for the non-blocking editions of these calls.
Regards,
Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Thu, Mar 29, 2012 at 1:10 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version of window.confirm() or window.alert(). Dialogs that are fully
in-page
Oops, got cut off here. What I meant to say is something like dialogs
that are fully in-page are the emerging standard for high-quality
page-modal prompting.
Non-blocking window.{alert,confirm,prompt} would most likely be rendered
by UAs as in-page overlays / tab-scoped dialogs. This is what we would do
in Chrome, and it seems like others would do the same given the prevalence
of the standard window.{alert,confirm,prompt} being implemented in a
tab-scoped manner already by some browsers (albeit with bugs).
I think people use alert, confirm and prompt in part because they are so
easy to use. People who choose window.{alert,confirm,prompt} probably
don't care about loss of customization or else they would roll their own
dialogs.
Why not provide less sucky versions of those common dialogs?
Benefit: Less code for simple dialogs.
Con: Another web platform API to standardize.
-Darin
Also, there is a downside to the current convention of custom drawing modal
dialogs. Web pages that mash-up content from varied sources would need to
have some convention for queuing up dialog requests. Ideally, modal
dialogs should be shown in FIFO order rather than all at the same time.
This seems like a tricky problem. It seems like something the platform
could help with. I believe the dialog proposal helps here. I think
non-blocking alert, confirm and prompt helps in a similar vein.
-Darin
I should add that this could be partly for path-dependent reasons, and
that if other technologies had been available, authors might not have
resorted to in-page modality with overlays. But I think the key missing
enabled was not asynchrony but rather the ability to fully control the UI,
layout and available commands of the modal experience.
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production debugging aid. In both cases, authors
who care about the user experience will use dialog or a JS-implemented
lightbox style dialog. And authors who do not care about user experience,
or who are doing a quick debugging hack in non-production code, will use
old-fashioned blocking alert/confirm/prompt. Thus, I am not sure there is
really a meaningful audience for the non-blocking editions of these calls.
Regards,
Maciej
Re: [whatwg] Encoding: big5 and big5-hkscs
On Wed, 28 Mar 2012 17:40:58 +0200, Philip Jägenstedt phil...@opera.com wrote: Making big5 and big5-hkscs aliases sounds like a good idea, on the assumption that big5-hkscs is a pure extension of Big5. I believe they are not, but given that a) Windows treats them identical and b) reportedly has no different default setup for Hong Kong and Taiwan users (and no longer offers a HKSCS download), they can probably be considered the same. For more details on Windows and Internet Explorer, see: http://lists.w3.org/Archives/Public/www-archive/2012Mar/thread.html#msg46 To make this more concrete, here are a few fairly common characters that I think are in big5-hkscs but not in big5, their unicode point and byte representation in big5-hkscs when converted using Python: 啫 U+556B '\x94\xdc' 嗰 U+55F0 '\x9d\xf5' 嘅 U+5605 '\x9d\xef' I'm not sure how to use big5.json, so perhaps you can tell me what these map to in various browsers? If they're all the same, examples of byte sequences that don't would be interesting. big5.json is the result of outputting all possible lead/trail byte combinations and then running charCodeAt over the resulting string, while accounting for surrogates and working around a minor problem in Opera. Running the following (Python): import json data = json.loads(open(big5.json, r).read()) lead = 0x9D trail = 0xF5 row = 0xFE-0xA1 + 0x7E-0x40 + 2 cell = (trail-0xA1 + 0x7E-0x40 +1) if trail 0x7E else trail - 0x40 index = (lead-0x81) * row + cell for x in data: print x, hex(data[x][index]) I get opera-hk 0x55f0 firefox 0x9c1f chrome 0xecd7 firefox-hk 0x55f0 opera 0xfffd chrome-hk 0x55f0 internetexplorer 0xecd7 indicating browsers agree for big5-hkscs and not at all for big5. Similar results for your other examples. It seems fairly obvious that the most sane solution would be to just use a more correct mapping that doesn't involve the PUA, but: 1. What is the compatible subset of all browsers? 2. Does that subset include anything mapping to the PUA? This depends on whether or not you include big5-hkscs results. Opera never maps to PUA, but whether that is compatible enough is unclear. 3. Do Hong Kong or Taiwan sites depend on charCodeAt returning values in the PUA? 4. Would hacks be needed on the font-loading side if browsers started using a more correct mapping? Don't know. Mozilla has done a number of interesting things here nobody else does, but that was all big in '05 or earlier. https://bugzilla.mozilla.org/show_bug.cgi?id=9686 https://bugzilla.mozilla.org/show_bug.cgi?id=310299 How relevant that is today, given that they are not the market leader there, is unclear. Given the information from Microsoft indicated at the start of this email I sort of think maybe just following Internet Explorer here is the best way forward, combined with strongly discouraging the usage of big5. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas v5 API additions
Thanks. Having looked at the changes, I think it might be more appropriate to put this as a third global option, e.g. globalAlpha, globalCompositeOperation and globalSmoothingEnabled (default true, because I think most implementations currently do smoothing). I think the option should definitely affect all rendering on the canvas (images, patterns, lines, possibly text?) since applications like retro games need a simple switch to affect everything, and the name globalSmoothingEnabled should better imply it will affect everything. Ashley On 29 March 2012 05:41, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Ashley Gullen wrote: BTW: - have you got a link to the spec including the smoothing property? can't seem to find it http://www.whatwg.org/specs/web-apps/current-work/#dom-context-2d-imagesmoothingenabled (I will be replying to your detailed feedback at some future point, but I wanted to make sure you had the link now in case you had any more feedback!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Client side value for language preference
Hello, on every HTTP request your browser sends header called
Accept-Language with a value something like this:
en-gb,en-us;q=0.7,en;q=0.3
This is sent to all domains wither your request is for an image, an
html file, a js script, or whatever. This gives server-side code some
nice capabilities, one of the foremost being the ability to localize
content.
As you all are well aware, more and more application logic is being
done on the client side. In some cases, even HTML templating is being
done there. In a few project I've been involved with recently it would
have been nice to be able to identify the user's preferred language
client side.
Browsers support a value called navigator.language but it does not
convey the same information as the HTTP header. On many browsers it
simply indicates which language the browser is localized in. For
example, if you speak Spanish but buy a computer in America which
comes with Firefox pre-installed then despite what language you prefer
it will be en-us.
Some browsers have gotten smarter and now send the first value from
the user's language preference, which is definitely an improvement. I
suspect this was done in order to preserve backwards compatibility, so
much of the useful information is left out.
What would be great is if client side scripts could access the same
information the server side code could access. That could be done
simply be creating a new property that contains the same string as is
sent to the server. It's easily parseable. But if we're going to make
a new interface then maybe it would be good to make one that reduces
the amount of work that client side developers would need to do.
A very naive and probably flawed example could be:
navigator.language.preference = [{lang:'en-gb', weight: 0.7},{lang:
'en-us', weight: 0.7},{lang:'en', weight: 0.3}];
Then JS could:
var n = navigator.language.preferences
for (i in n) {
// check if n[i].lang is supported by the application, if so do
something about it
}
This would give users a list of languages with the first in the list
being the most preferred.
Another option is:
navigator.language.preferences = { en-gb: 0.7, en-us: 0.7, en: 0.3 }
(thanks to Corey Frang for suggesting this)
It's definitely nice and terse but I wasn't sure if browsers
consistently returned the properties in the order they're defined. If
so then this code would work:
for ( locale in navigator.language.preferences ) {
// if locale is supported by the application then break
}
locale is the user's first choice that is supported by the application
Why am I writing this? Well, my hope is that browser makers will see
the value of being able to access this property client side and
provide a consistent way to access it.
I'd love to hear your thoughts on the matter, also thanks for
considering my first post to the list.
--
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter
♫ You're never fully dressed without a smile! ♫
Re: [whatwg] Client side value for language preference
2012-03-29 22:02, Matthew Nuzum wrote:
Hello, on every HTTP request your browser sends header called
Accept-Language with a value something like this:
en-gb,en-us;q=0.7,en;q=0.3
– –
Browsers support a value called navigator.language but it does not
convey the same information as the HTTP header.
Browsers have different features in this respect, but indeed they are
quite distinct from the language preferences.
The language preferences used to have little impact, because few sites
made use of them. And most users never learned about them, and there was
little reason to learn… and therefore the settings are often inadequate,
so it was a vicious circle. Well, still is. But interactive applications
like many Google services are changing the situation: the language
preferences sent are used to affect the language in generated texts and
user interfaces, rather than just selecting between language versions of
documents.
Some browsers have gotten smarter and now send the first value from
the user's language preference, which is definitely an improvement.
I think browsers have generally sent an Accept-Language header
constructed from user preferences, for many years. The problem is that
these settings seldom reflect the user’s real preferences, because the
defaults generally depend on the browser language, or on the system
language, not on any action by the user. If you use an English-language
browser, the preference defaults might contain just English in different
flavors, even though English might be the user’s fourth-best language.
What would be great is if client side scripts could access the same
information the server side code could access.
Sounds like a useful thing. It would support the idea of enabling
standalone applications that can run offline, too. Along similar lines,
it might be useful to give access to other settings that affect HTTP
headers, but language settings seem to be far more important than other
settings.
Note, however, that the idea postulates a simple model where the header
only depends on certain settings and is the same for all resources. But
this is probably acceptable. It is difficult to imagine a situation
where a user preferred HTML documents in French and images in Italian,
for example.
That could be done
simply be creating a new property that contains the same string as is
sent to the server. It's easily parseable. But if we're going to make
a new interface then maybe it would be good to make one that reduces
the amount of work that client side developers would need to do.
I think the simple idea of a string is the best way to go. Anything
beyond that can be handled by a library that can be written in a
cross-browser way—not quite trivial, but surely doable. The problem is
to get some basic data from the browser in well-defined way. I’d suggest
a name like
navigator.acceptLanguage
A very naive and probably flawed example could be:
navigator.language.preference = [{lang:'en-gb', weight: 0.7},{lang:
'en-us', weight: 0.7},{lang:'en', weight: 0.3}];
Then JS could:
var n = navigator.language.preferences
for (i in n) {
// check if n[i].lang is supported by the application, if so do
something about it
}
This would give users a list of languages with the first in the list
being the most preferred.
Actually, it’s the q (weight) values that matter, not the order, so a
routine that selects the most preferred language would need to compare
them. Moreover, the language negotiation mechanism can be more
complicated: it need not select the language with highest q value, since
the resources themselves may have been classified as having different
qualities. This might not matter in most cases, but applications should
still have access to the full information, with q values, either in form
of an Accept-Header string or as a constructed array or object. I’m just
spelling this out to emphasize that simple information about the most
preferred language is not enough, even if the information is taken from
user preferences.
Yucca
Re: [whatwg] iframe sandbox attribute
I guess I don't see much value in using DOMSettableTokenList for the sandbox property. I don't expect folks to mutate the property much. They're just likely to set it to a constant and be done with it. The situation is very different for a property like className, where there's a strong use case for mutating. Adam On Mon, Mar 26, 2012 at 4:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/26/12 3:19 PM, Ian Hickson wrote: Changing it to a string doesn't affect that, though, does it? Well, changing to a nullable string does affect it because doing something like this: myFrame.sandbox = myFrame.sandbox; is a no-op, as by all sane rights it should be More importantly, myOtherFrame.sandbox = myFrame.sandbox; doesn't have weird surprising behavior if the attribute is something whose value sanely distinguishes between the various possible sandbox values. We can certainly add an attribute to DOMSettableTokenList (or rather, a descendant, for use specifically with iframe.sandbox) that does the same as .hasAttribute(), e.g.: iframe.sandbox.present ...or something, if that would help. Would we also make the attribute readonly, then, and require that it be set via the token list? Otherwise, it seems like the snippets above would still have pretty unexpected behavior. But even then they might, since sets of readonly props are just silently ignored. :( -Boris
