[widgets] localizing author
Hi, I just realised that I actually localise my own name in certain languages (most particularly to ensure that I get my preferred transliterations when I am publishing). But I cannot do that in config.xml. Likewise, I would like to localise the href for me which would be possible if I could localise the author element but isn't at the moment. I don't now if this is too late for the current version, in which case please log it as an issue for the future. Changing it to allow localisation would mean a change to the schema - and at least to Opera's implementation. I haven't yet checked (I only realised I want to do this but it isn't allowed today) whether we have any preference for making that change now or later. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Support for matchesSelector()
Hi,
The matchesSelector() method has been implemented by both Mozilla [1]
and WebKit [2], and we are implementing the same level of support for it
as they did (without support for :scope or refNodes parameter).
However, both Mozilla and WebKit opted to implement it using prefixed
methods, and I'm wondering if people from Mozilla and WebKit could
explain their justification for using a prefix?
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary because:
1. Using refNodes without using the :scope selector has no effect and
additional parameters are just ignored.
e.g. el.matchesSelector(a, [el1, el2]); works now as defined.
2. Using the :scope selector in existing implementations will throw a
syntax error.
This means that if a script in the future wants to use a selector with
:scope, they will still be able to detect whether or not a given browser
supports it using a try/catch block.
e.g.
try {
var x = el.matchesSelector(:scopea, [el1]);
} catch (e) {
// Use alternative technique here to check.
}
3. The existing querySelector methods also don't have a prefix, but
selectors api 2 also extends those in the same way with refNodes. This
should not be a problem for those methods.
Therefore, I would like to get feedback from others, particularly the
Mozilla and WebKit developers about this approach, and find out whether
Mozilla and WebKit will also consider dropping the prefix?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=518003
[2] https://bugs.webkit.org/show_bug.cgi?id=29703
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Support for matchesSelector()
On 4/8/11 6:44 AM, Lachlan Hunt wrote: However, both Mozilla and WebKit opted to implement it using prefixed methods, and I'm wondering if people from Mozilla and WebKit could explain their justification for using a prefix? Sure. In Gecko's case, we implemented in October 2009. The first spec draft that mentions matchesSelector appeared in January 2010. So at the time we were implementing, there was no indication that the name, the number of arguments, the meaning of the arguments, etc would not change as said spec draft was written. We are thinking that implementing with a prefix as Element.oMatchesSelector() is unnecessary Well, one obvious question is whether we now have good reasons to believe that the name and number/meaning of the arguments won't change. 2. Using the :scope selector in existing implementations will throw a syntax error. That seems, to me, like something that should prevent unprefixing, no? This means that if a script in the future wants to use a selector with :scope, they will still be able to detect whether or not a given browser supports it using a try/catch block. Yes, but should it have to? 3. The existing querySelector methods also don't have a prefix, but selectors api 2 also extends those in the same way with refNodes. This should not be a problem for those methods. This is true, for the reasons you described, but trying to use the new features for the existing methods does involve that try/catch pattern you noted. But should we really require its use for matchesSelector? There are obvious benefits to having matchesSelector support imply that :scope is supported too... I should note that the way the old methods were extended is somewhat worrisome: as soon as a UA implements the new refNodes thing we're stuck with it. So I really hope that either we're very sure that's what we want to do or that UAs are careful about implementing until we get to that very sure level. I'd prefer the former, since I've been considering implementing this stuff. -Boris
Re: Support for matchesSelector()
On 4/8/11 6:44 AM, Lachlan Hunt wrote: 2. Using the :scope selector in existing implementations will throw a syntax error. On which note, it seems like :scope will first show up prefixed as well, right? -Boris
:scope definition ambiguity
In the text at http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class the term belongs to a document is not defined. Does it mean there is a Document on the parent chain, or does it mean ownerDocument is not null? -Boris
Re: :scope definition ambiguity
On 4/8/11 9:24 AM, Boris Zbarsky wrote: In the text at http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class the term belongs to a document is not defined. Does it mean there is a Document on the parent chain, or does it mean ownerDocument is not null? Then again, maybe it doesn't matter now that I think about it. In which case, do we just want to define :scope as matching the documentElement of the ownerDocument of the element in question? -Boris
Re: Support for matchesSelector()
On 2011-04-08 18:22, Boris Zbarsky wrote: On 4/8/11 6:44 AM, Lachlan Hunt wrote: 2. Using the :scope selector in existing implementations will throw a syntax error. On which note, it seems like :scope will first show up prefixed as well, right? Yes, that's reasonable. In which case, do we just want to define :scope as matching the documentElement of the ownerDocument of the element in question? Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] localizing author
On 8 Apr 2011, at 09:42, Charles McCathieNevile wrote: Hi, I just realised that I actually localise my own name in certain languages (most particularly to ensure that I get my preferred transliterations when I am publishing). But I cannot do that in config.xml. Likewise, I would like to localise the href for me which would be possible if I could localise the author element but isn't at the moment. Many of my Chinese colleagues also have an English name as well as a Chinese name; the English name isn't a translation or transcription of the Chinese name, its often completely different. I can also see the point of localized hrefs - again I have colleagues who may want to point to a Facebook profile page in English, and a RenRen one in Chinese. I guess the workaround at present is to use the element to do something like author王密 (Michelle Wang)/author ... which is not completely ideal as you don't get different hrefs. I don't now if this is too late for the current version, in which case please log it as an issue for the future. Changing it to allow localisation would mean a change to the schema - and at least to Opera's implementation. I haven't yet checked (I only realised I want to do this but it isn't allowed today) whether we have any preference for making that change now or later. I presume the change would be to make Author multiple with xml:lang. I think a risk is that developers might reasonably interpret this as meaning one author element for each person rather than one author element per locale. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
