I have to admit that I am reading this spec thinking about rounded
display[1] (aka. watch) and this probably requires brainstorms instead
of this nitpicking, but whatever.
The current spec seems to leave screen.orientation.lock("landscape")
undefined for the case when the screen width and height a
(12/11/26 22:11), Kang-Hao (Kenny) Lu wrote:
> (12/11/26 21:25), Anne van Kesteren wrote:
>> I agree with Ian's other observations/comments.
>
> I suppose that doesn't include
>
> (12/11/24 5:22), Ian Hickson wrote:
>> Also, the document asks for feedback on
(12/11/26 21:25), Anne van Kesteren wrote:
> I agree with Ian's other observations/comments.
I suppose that doesn't include
(12/11/24 5:22), Ian Hickson wrote:
> Also, the document asks for feedback on the public-webapps list, but
> that fragments feedback on the spec; the WHATWG copy instead sug
(12/11/24 1:28), Adam Barth wrote:
>> Now, that being said and seeing as we cannot put Anne as an editor of the
>> W3C version of the spec (because, technically, he's not). How do you guys
>> suggest we go about acknowledging the WHATWG source? Where in the spec? How?
>> With what kind of wording?
(12/08/21 19:34), Arthur Barstow wrote:
> On 8/20/12 5:05 PM, ext Michael[tm] Smith wrote:
>> Arthur Barstow , 2012-08-20 08:11 -0400:
>>> On Thu, Aug 16, 2012 at 10:00 AM, Kang-Hao (Kenny) Lu
>>> wrote:
>>>>> We have public-webapps-bugzilla[1] already,
(12/08/17 0:36), Dimitri Glazkov wrote:
> Another idea is to have a separate mailing list for this. At least,
> there will be some opt-in step that will give other
> public-webapps-nauts at choice.
We have public-webapps-bugzilla[1] already, but I have no idea why we
can't just turn on the compone
(12/08/06 19:25), Lachlan Hunt wrote:
> On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote:
> I'd rather find a way to address the issue. I've just been a bit busy
> with other tasks for the last 2 weeks to look into this.
>
> I'd like feedback from implementers about
(12/07/31 20:06), Arthur Barstow wrote:
> On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote:
>> Sorry for my late comment.
>>
>> While I think it's fine to publish LCWD Selectors API as it is, it would
>> be nice if it can address my comment in [1]. By "
Sorry for my late comment.
While I think it's fine to publish LCWD Selectors API as it is, it would
be nice if it can address my comment in [1]. By "address", I mean either
define the desired behavior or explicitly mark it as undefined (which I
think is better than not saying anything because an e
(12/06/21 23:28), Charles McCathieNevile wrote:
> On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu
> wrote:
>> (12/06/20 22:26), Lachlan Hunt wrote:
>>> The least-objectionable alternative is rarely the best alternative, and
>>> trying to please everyone is
(12/06/20 22:26), Lachlan Hunt wrote:
> On 2012-06-20 10:42, Charles McCathieNevile wrote:
>> In other words we have the same arguments that we had five years ago,
>> when we settled on querySelector as the one that provoked least
>> objection.
>> ...
>> But spending another few months arguing abou
(12/06/18 22:45), Simon Pieters wrote:
> I think we should instead either fix the old API (if it turns out to not
> Break the Web) or live with past mistake (if it turns out it does). To
> find out whether it Breaks the Web (and the breakage can't be evanged),
> I suggest we ship the backwards-inco
(12/06/17 21:33), Anne van Kesteren wrote:
> Always throwing SyntaxError is probably better.
I have no opinion here besides that I think this should be well-defined.
(12/06/17 21:50), Aryeh Gregor wrote:
> I'm not sure what Anne meant, but I'd think we should just always
> require SyntaxError, i
The spec (either Level 1 or Level 2) is unclear about which error should
be raised in a situation when both NAMESAPCE_ERR and SYNTAX_ERR apply,
and this is not the same in all browsers. That is, for a selector like
a|b +
or
a|b, +
IE9, Firefox 13 and Opera12alpha raise NAMESAPCE_ERR, while
(12/03/27 6:30), Glenn Adams wrote:
> On Mon, Mar 26, 2012 at 4:23 PM, Kang-Hao (Kenny) Lu <
> kennyl...@csail.mit.edu> wrote:
>
>> (12/03/27 5:43), Glenn Adams wrote:
>>> my position is that, unless somewhere it is documented what the
>> convention
>&g
(12/03/27 5:43), Glenn Adams wrote:
> my position is that, unless somewhere it is documented what the convention
> "associated with" means, that it is (1) ambiguous, and (2) can be
> interpreted in any of the above four ways;
This is still lacking context, but in general I agree with you.
> this
http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html
SUN Haitao found the description of the Traditional Chinese IME used as
an example in this use cases document somewhat inaccurate.
3.1.2 Radical composer
__
# typing ‘o’ produces ‘人’ on a Traditional-Chi
(Bcc public-webapps and public-i18n-cjk)
9.2.3. Input method editor: the ‘ime-mode’ property
I did some testing about this property[1] to get a sense of what this
property is doing exactly. Here are some of the issues:
# Applies to: text fields
In IE9, 'ime-mode' applies to elements with @con
(12/02/04 10:50), Boris Zbarsky wrote:
> On 2/3/12 8:52 PM, Kang-Hao (Kenny) Lu wrote:
>># Unexpected end of style sheet. User agents must close all open
>># constructs (for example: blocks, parentheses, brackets, rules,
>># strings, and comments) at the end of
(12/02/04 10:50), Boris Zbarsky wrote:
> On 2/3/12 8:52 PM, Kang-Hao (Kenny) Lu wrote:
>># Unexpected end of style sheet. User agents must close all open
>># constructs (for example: blocks, parentheses, brackets, rules,
>># strings, and comments) at the end of
(Bcc public-webapps as this case is only observable via the Selectors API)
I found an edge case where the relevant specs don't provide a consistent
answer. Consider,
document.querySelector("html /* ")
should it throw or not?
The Selectors API calls the following production "selector string"
(11/12/21 23:47), Anne van Kesteren wrote:
> On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
> wrote:
>> 1. The spec says the timeout should fire after the specified number of
>> milliseconds has elapsed since the start of the request. I presume
>> this means literally that, with no bearing o
(11/08/09 16:57), Masayuki Nakano wrote:
> 3. Some web developers may not know well about IME behavior. Their web
> applications might break IME behavior by handling key events.
>
> I'd like to *suggest* that key events shouldn't be fired during IME
> composition, especially for #3. If web develop
Hello Makoto,
(Cc+ public-webapps)
(11/02/25 15:16), Makoto Kato wrote:
> Hi,
>
> This is simple sample. This behavior is different on all web browsers
> when input element has composition/preedit string for IME.
A relevant question here, I think, is where the cursor should go when
the value of
24 matches
Mail list logo
