Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 4:47 PM, Tab Atkins Jr. wrote: > > > Just throw away your notion that .find() does any scoping whatsoever. > Ok, will do. > It doesn't; all it does is provide a reference element, which is > matched by :scope and which is used to absolutize relative selectors. > > ~TJ >
Re: [selectors-api] QSA and findAll definitions
On Mon, Jun 10, 2013 at 1:15 PM, Timmy Willison wrote:
> Thank you both. That helps a lot. I figured el.querySelector(":scope + div")
> would do the same thing as el.find("+ div").
>
> Perhaps more examples in the spec that clearly demonstrate differences like
> this between qSA() and findAll() would be helpful. I think some form of the
> example that Tab gave would be a great addition.
>
> Also, maybe we can clarify even further in the defintions for find() and
> findAll(). Perhaps, rather than,
>
> "... from the tree within which the context object is located."
>
> It could be,
>
> "... within the subtrees of the parent of the context object or the tree in
> which the context object is located if there is no parent."
>
> Compare this with qS[A]:
>
> "... within the subtrees of the context object."
>
> This is an attempt to make it clear that ancestors of the context object
> will never be in the resulting set and need not be considered in
> implementations. In other words, it seems to me that elem.find() will never
> return ancestors of elem.
It certainly can return ancestors. You just need the right
combinators. The reference combinator defined in Selectors 4
can move
anywhere in the tree, including straight upwards. The use of the
subject indicator, also defined in Selectors 4
, can also move up the
tree.
Just throw away your notion that .find() does any scoping whatsoever.
It doesn't; all it does is provide a reference element, which is
matched by :scope and which is used to absolutize relative selectors.
~TJ
Re: [selectors-api] QSA and findAll definitions
Thank you both. That helps a lot. I figured el.querySelector(":scope +
div") would do the same thing as el.find("+ div").
Perhaps more examples in the spec that clearly demonstrate differences like
this between qSA() and findAll() would be helpful. I think some form of the
example that Tab gave would be a great addition.
Also, maybe we can clarify even further in the defintions for find() and
findAll(). Perhaps, rather than,
"... from the tree within which the context object is located."
It could be,
"... within the subtrees of the parent of the context object or the tree in
which the context object is located if there is no parent."
Compare this with qS[A]:
"... within the subtrees of the context object."
This is an attempt to make it clear that ancestors of the context object
will never be in the resulting set and need not be considered in
implementations. In other words, it seems to me that elem.find() will never
return ancestors of elem.
On Mon, Jun 10, 2013 at 10:53 AM, Tab Atkins Jr. wrote:
> On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky wrote:
> > On 6/9/13 7:35 PM, Timmy Willison wrote:
> >> I was a little confused. I realized something I already knew in that
> >> elem.querySelector[All] does limit the matched set to the descendants of
> >> element
> >
> > Right. But find() does not, for what it's worth, depending on the exact
> > selector used. It can return sublings of the context object, for
> example,
> > as far as I can tell. Hence the wording difference.
>
> Specifically, "el.find('+ div');" will work, and find the sibling
> to the context element. "el.querySelector(':scope + div');"
> will *not* work, because the results are first filtered to be only
> descendants of the context element.
>
> The wording is slightly confusing now, but in Selectors 4 terminology,
> selectors in find() are *relative*, but not *scoped*. Selectors in
> qSA() are scope-filtered. (They may also be relative - it's been a
> while since I read the spec, so I don't remember.)
>
> ~TJ
>
>
Re: [selectors-api] QSA and findAll definitions
On Sun, Jun 9, 2013 at 6:18 PM, Boris Zbarsky wrote:
> On 6/9/13 7:35 PM, Timmy Willison wrote:
>> I was a little confused. I realized something I already knew in that
>> elem.querySelector[All] does limit the matched set to the descendants of
>> element
>
> Right. But find() does not, for what it's worth, depending on the exact
> selector used. It can return sublings of the context object, for example,
> as far as I can tell. Hence the wording difference.
Specifically, "el.find('+ div');" will work, and find the sibling
to the context element. "el.querySelector(':scope + div');"
will *not* work, because the results are first filtered to be only
descendants of the context element.
The wording is slightly confusing now, but in Selectors 4 terminology,
selectors in find() are *relative*, but not *scoped*. Selectors in
qSA() are scope-filtered. (They may also be relative - it's been a
while since I read the spec, so I don't remember.)
~TJ
Re: [editing] nested contenteditable
On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai wrote: > The main use case I can think of for mixed editability is an image with a > caption. If anyone has other use-cases, that would be helpful in reasoning > about this. http://jsfiddle.net/UAJKe/ A video with JavaScript controls comes to mind. Any embedded widget, really. > Looking at that, I think we should make it so that a selection can never > cross an editing boundary. So, in the image caption example, put your cursor > right before the uneditable div, then: > 1. Right arrow should move your cursor into the caption text. > 2. Shift+right arrow should select the whole uneditable div. > > And delete/backspace can just be defined as extending the selection one > position and then removing the selected DOM. Relatedly, if you are at the > beginning of the caption text and hit backspace, nothing happens because the > backspace had nothing to select (i.e. selections are contained within their > first contentEditable=true ancestor). Delete/backspace are more complicated than just selecting one position and removing. For instance, backspacing at the beginning of a block is complicated, and the spec says (following Word and OpenOffice) that backspacing after a link should unlink it rather than delete the last character. (Browsers don't do the latter yet, but it's particularly essential when autolinking is supported -- otherwise it's annoying to unlink something that the browser helpfully linked it without asking you.) The rest of what you say sounds reasonable. > As to the question of whether delete/backspace should select or remove > non-editable elements, I'm not opposed to giving this a try in Chromium and > seeing if users are confused by it, but I'm skeptical it will make sense to > people. I'm not sure either. It's what the "behavior when typing in contentEditable elements" document recommends for tables. Maybe it makes more sense to just delete it, and assume the user is clever enough to undo if they didn't want it deleted.
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
Hi there, On Mon, Jun 10, 2013 at 10:58 AM, Lars Knudsen wrote: > IMO, this would be a much more clean and easy to understand solution than > providing a separate API for orientation lock. It would also remove 1 > "unknown" element when game developers try to juggle mappings between > xyz-accelerometer data vs media query orientation vs "device normal > orientation" (as some propose to have "natural landscape" and "natural > portrait" devices - something I really think would just add to the > confusion). That is good to hear; it is very important that all this feel natural to developers without digging into a lot of spec details. Kenneth
Re: [screen-orient] why not provide at CSSOM API to CSS Device Adaptation instead?
On Wed, Apr 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen < kenneth.r.christian...@intel.com> wrote: > Hi there, > > CSS Device Adaptation should hopefully be enabled on all browsers (desktop > and mobile) unlike the viewport meta tag, which cannot be enabled on > desktop browsers easily as many desktop sites actually comes with a > viewport meta tag which is ignored. Having that not being ignored breaks > the sites. > > MS already enabled a subset of the CSS Device Adaptation spec in IE10 > desktop. > > I support adding some CSSOM API's for CSS Device Adaptation, but I would > not do so for the viewport meta tag, which has its share of issues. I would > also like the CSS Device Adaptation, orientation lock and Fullscreen to > integrate. Especially it would be nice to click on an element in portrait > and have it go fullscreen in landscape mode and lock, all with a nice > animation. > IMO, this would be a much more clean and easy to understand solution than providing a separate API for orientation lock. It would also remove 1 "unknown" element when game developers try to juggle mappings between xyz-accelerometer data vs media query orientation vs "device normal orientation" (as some propose to have "natural landscape" and "natural portrait" devices - something I really think would just add to the confusion). Allow me to quote myself from an earlier other thread on a proposed orientation lock API: " As long as both MediaQueries, xyz-accelerometer data, orientation lock and more *all* are aligned, this could work. However, we need to have this tested with a bunch of developers - to see where they make mistakes caused by possible confusion. My own opinion on this is still to keep it in a specific orientation also (e.g. "portrait up") as 0 degrees, as it makes everything more easy to handle when the basics are kept static. I can tell you that even inside the same company (mobile phone manufacturer), I have seen mistakes in the mapping of the xyz-accelerometer values *alone* between units coming from slightly different branches. This was because some were "landscape" devices and some were "portrait" and everything have to match from the low level HW to the high level javascript API. If we make sure that a device - no matter how the rest of the UI is turning - is always considered "0 degrees" when held - e.g. "portrait up", (x,y,z) = (0,1,0), then: 1. non-game developers can be happy with "lock to landscape" and never need to worry about the inner workings and 2. game developers (using the accelerometer) won't have to reinvent strange mappings when juggling media queries, accelerometer and orientation lock. If we allow "natural landscape" units and "natural portrait" units - then in some cases, when in a landscape locked game, the gravity goes in the direction of "negative X" - and in some cases it goes in the direction of "negative Y". And it gets worse if you don't even know which landscape (left or right up) you got. If we enforce that the device always has "0 degrees" when held portrait up (Y positive pointing at 90 degrees) - then "lock to landscape right up" always gives gravity in "negative X". " The problem might sound like a small one - but as a web game developer, I would MUCH rather develop for devices, where I know that "in my landscape-left game, natural UP is X+" than being forced to buy and test on all thinkable devices out there because the spec allows for manufacturers to have "natural landscape" units, where "full screen portrait" could be anything (really) when mapping the xyz accelerometer data to my game. br Lars > > Cheers > Kenneth > > > > On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel wrote: > >> Hi, >> >> Screen orientation lock is critical to a whole set of mobile games >> (especially those which rely on the accelerometer to control the gameplay). >> It's great that it is now considered for specification and implementation. >> >> I had collected some use cases a while back[1], some of which led to >> use-cases[2], requirements[3] and suggestions[4] in the Coremob report. >> >> While some of the original use cases required dynamically modifying >> orientation lock (e.g. the Game within a game experience[5]), key use cases >> simply require a declarative, page-wide setting, as described by David >> Bruant on the WHAT WG mailing list[6]. >> >> The current proposal[7] only targets the dynamic setting through a JS API >> and leaves the more declarative approach to other specs[8]. It mentions the >> Web Application Manifest Format and Management APIs[9] and CSS Device >> Adaptation[10]. >> >> Now, CSS Device Adaptation, as used in the Viewport META element[11] is >> ubiquitous on mobile. It seems like a natural fit for a declarative >> orientation lock, so much so that it's already specified in the spec[12]. >> >> However, the syntax to dynamically read or modify the Viewport META >> element is cumbersome and error prone (you're talking document.cookie-like >> string s
