Re: [IndexedDB] Straw man proposal for moving spec along TR track

[Joshua Bell]

*crickets*

Given the state of the open issues, I'm content to wait until an editor has
bandwidth. I believe there is consensus on the resolution of the issues and
implementations are already sufficiently interoperable so that adoption is
not being hindered by the state of the spec, but should still be corrected
in this version before moving forward.

On Wed, Nov 28, 2012 at 9:02 AM, Arthur Barstow wrote:

> It's been a month since we talked  about the next publication steps for
> the IDB spec (#Mins). Since then, I am not aware of any work on the
> #LC-comments tracking. As such, here is a straw man proposal to move v1
> forward:  ...
>
> * Forget about processing #LC-comments
>
> * Mark all open #Bugsfor v.next
>
> * Start a CfC to publish a new LC based on the latest #ED "as is". (If
> Jonas commitsto making some important changes, that would be fine too but I
> don't think we want to includeany "feature creep" or API breaks.)
>
> Re v.Next, I recall Jonas said he was willing to continue to be an Editor
> but I am not aware of anED being created. If/when a new ED is created, we
> can work toward a FPWD.
>
> Comments?
>
> -Thanks, AB
>
> #Mins 
> 
> >
> #Bugs  WebAppsWG&component=Indexed%**20Database%20API&resolution=--**
> -&list_id=2509
> >
> #ED 
> 
> >
> #LC-comments  IndexedDB%20Disposition%20of%**20Comments.html
> >
>
>
>
>

Re: [WebIDL] Representing functions that user code can call

[Dimitri Glazkov]

On Sun, Dec 9, 2012 at 8:16 PM, Boris Zbarsky  wrote:
>
>
>>function CustomElementConstructor = Element ();
>>
>>partial interface Document {
>>  CustomElementConstructor register(DOMString name,
>>optional Options options);
>>};
>>
>
> Yep.


Should I just pretend the world is perfect and use this syntax in spec? :)

:DG<

Call for Review: Web IDL Testing document

[Arthur Barstow]

[ Bcc: public-webapps ; please reply to public-script-coord ]

This is a Call for Review of Travis' Web IDL Testing document:



In particular, we are interested in feedback and contributions on the 
following:


* Are the assertions that are already defined (see Section 3 in the 
Testing document), valid?


* Identify the additional assertions needed to form the test suite. 
(Travis stopped on section 4.2.5 of #CR.)


* Maciej suggested (#Mins) building a conformance table to see where 
there aren't two implementations that match each WebIDL assertion. 
Thatwill be the next step after getting the initial set of assertions 
identified.


* We want to prioritize any specs that may be blocked on certain aspects 
of WebIDL conformance, to be sure to get those assertions completed and 
reviewed first. If a particular spec is blocked on a specific WebIDL 
feature, please let us know so we can prioritize it. The specs 
identified as having a Web IDL dependency are:




-Thanks, AB

#CR 
#Mins 


 Original Message 
Subject: 	ACTION-670: Start a Call for Review for Web IDL test plan on 
public-script-coord (Web Applications Working Group)

Date:   Mon, 29 Oct 2012 11:10:42 +
From: 	ext Web Applications Working Group Issue Tracker 


Reply-To:   Web Applications Working Group 
To: 



ACTION-670: Start a Call for Review for Web IDL test plan on 
public-script-coord (Web Applications Working Group)

http://www.w3.org/2008/webapps/track/actions/670

On: Arthur Barstow
Due: 2012-11-05

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

[Bug 20322] New: Document the force preflight flag

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322

Bug ID: 20322
   Summary: Document the force preflight flag
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

It would be good to add some details here. The main thing it prevents detecting
I think is the existence of another server, but whether that's useful given
that you can already discover it via  I'm not sure, and we might be able
to address it in a better way?

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

Re: [webcomponents] Custom Components and CSS Regions

[Dominic Cooney]

On Fri, Dec 7, 2012 at 10:52 AM, Alan Stearns  wrote:

> >On 12/6/12 3:25 AM, "Dominic Cooney"  wrote:
> >
> >>On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns  wrote:
> >>
> >>...
> >>
> >>An insertion point is a  element inside a shadow DOM subtree.
> >
> >This is one kind of insertion point. There is a second kind,
> >called , which is used when multiple shadow roots are
> >applied to a given element to specify how the shadows are
> >merged for rendering.
>
> Thanks for the correction.
>
> >...
> >
> >>Insertion Points:
> >>1. Content assignment done in HTML
> >>2. One-to-one mapping of content to insertion point
> >
> >If you replace /insertion point/ with /content element/ this
> >is right for the children of a given host element in the context
> >of that host element¹s shadows but not for a document in general.
> >When there are multiple shadows and reprojection, where a node
> >is presented in the (virtual) flattened tree can depend on
> >multiple insertion points.
>
> What I mean here is that the end result is a simple mapping for each
> content element to a specific insertion point. The end result may depend
> on multiple insertion points, but there's always just one insertion point
> where each content element gets displayed. I am trying to contrast this
> with taking content and flowing it between two boxes as you can do with
> CSS Regions (my first use case below).


Yes, this is the qualitative difference.


> >>3. Content must come from insertion point shadow host
> >
> >This is incorrect in the case of reprojection.
>
> Would it be more precise to say that the content must come from somewhere
> up the parent chain? Here I'm trying to contrast between the scoped
> selectors that insertion points use and the general selectors that can
> have flow-into assignments. This fits in to my multiple source use case
> (#4) below.
>

To be precise you have to define “parent chain” very carefully, but yes –
Shadow DOM projection pulls content from a defined scope; CSS Regions have
more of a flat, global namespace going on where content is pushed into
flows and is pulled from flows.


> >...
> >
> >>4. Can assign multiple selectors to a single insertion point
> >>5. Cannot chain insertion points together
> >
> >I¹m not sure what you mean by ³chain², but reprojection and
> > make two kinds of chaining possible.
>
> By chain I mean create a fragmentation context - akin to multicolumn
> layout. The column boxes are "chained" together and content flows from one
> column to the next. In CSS Regions each region box participates in a
> region chain, and content flows from one box to another.
>

Ah, I understand now. This is right.


> >...
> >
> >>Should use Regions
> >>1. If you need to chain boxes together inside a template
> >>  (create your own multicol component)
>
> Here I'm not thinking so much of faithfully recreating multicol layout,
> but of making a custom element that contains two or more columns
> (expressed as CSS Regions). Take a simple case of displaying your content
> in two columns separated by some graphical element in the gutter between
> the columns. Which content fits in the first column depends on its height
> and width, and any overflow content in the block direction flows into the
> second column. You can do this with CSS Regions defined in your template.
> I do not think you can do this with insertion points without choosing how
> to divide the content between the columns.
>
> >>...
> >>
> >>4. If you need to pull content from multiple sources
> >>  (breaking news from two or more components)
>
>
> Consider the Shadow DOM example of the news widget separating breaking
> news into its own section. What if you had two or more of these news
> widgets (say, international and local news) and you wanted to combine the
> breaking news from each into its own widget? You could create a "news
> page" widget that contained the list of news widgets in order to get
> access to all of the breaking news content across the widget list. But
> that would require an additional wrapper in the HTML.
>
> Instead, you could just add a "breaking news" widget, assign all of the
> .breaking content to a named flow, then assign that named flow to an
> element in the "breaking news" widget. CSS Regions can pull content out of
> each custom element (or anywhere else) and redirect it to a separate
> custom element without requiring a common parent.
>
> Thanks,
>
> Alan
>
>