[Bug 23332] Support Binary Keys

2013-09-23 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332

Joshua Bell jsb...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |LATER

--- Comment #1 from Joshua Bell jsb...@google.com ---
Marking RESOLVED=LATER since we're not doing this in v1, but we can dump ideas
here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 23332] New: Support Binary Keys

2013-09-23 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332

Bug ID: 23332
   Summary: Support Binary Keys
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
  Assignee: dave.n...@w3.org
  Reporter: jsb...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Suggested by Joran Greef jo...@ronomon.com 

Mailing list discussion:

http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0816.html

Summary: Seems like a good idea, but not for V1. Also tracked on:

http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: [webcomponents]: The Shadow Cat in the Hat Edition

2013-09-23 Thread Tab Atkins Jr.
On Thu, Sep 19, 2013 at 4:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 So, to be clearer, we'd be adding two new combinators, ^ and ^^.
 ^, the shadow combinator (or hat), pierces the upper-boundary
 encapsulation of a shadow root. The LHS has to be a component,
 something with an actual shadow root.  ^^, the all shadows
 combinator (or cat, or double-hat), is identical, but it pierces
 *all* shadow root upper boundaries.

Further use-case exploration by the Polymer folk has revealed that
this definition of ^^ is a bit too weak for a lot of reasonable
use-cases.

One of the major uses of ^^ is to simply target all x-foo elements
for styling.  Unfortunately, this means you need to ugly up your
selectors:

x-foo + div.bar, * ^^ x-foo + div.bar {...}

As far as they could tell from use-case exploration, this is by far a
more common use than what's implied by the stricter form defined in
the quote above.

To fix this, we propose that ^^ should instead be interpreted as
simply a more powerful descendant selector.  Writing * ^^ x-foo
will selector *all* x-foo elements within your context, or in lower
contexts.  (It'll miss the root element if it's an x-foo, but that's
probably rare, and you can catch it by just writing a selector like
what I wrote above.)


Related to this, we have to figure out what the relative strength of
selectors are in different trees.  Again, according to use-case
exploration, it seems that styling *inside* a component is basically
always setting *defaults*, which should be overrideable by the outside
world.  To address this in a reliable way, I propose adding another
Cascade layer 
http://dev.w3.org/csswg/css-cascade/#cascadinghttp://dev.w3.org/csswg/css-cascade/#cascading,
between Origin and Scope, which is Tree-of-Trees position.  Higher
trees (closer to the document root) beat lower trees.  Sibling trees
(which can happen when a single element has multiple shadow roots
attached) are youngest-beats-oldest.

(I had thought to handle this with my proposal for setting styles to a
default origin, but it doesn't quite mesh.  My !default idea makes
a style which loses to *everything* non-default, including
inheritance.  The Polymer people didn't want things *this* weak.)

~TJ