Re: [IndexedDB] link to Editor's draft is a 404

[Tobie Langel]

On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith  wrote:
>
> Arthur Barstow , 2015-02-02 08:47 -0500:
> > Archived-At: 
> > On 2/2/15 7:14 AM, Tobie Langel wrote:
> >
> > >Would recommend redirecting to the ED of the next version of the spec.
> >
> > That makes sense to me.
>
> Yup, sorry about thatーI forgot a step when we migrated the repos. But I've
> now set up the redirects and things should be working as expected. If not
> lemme know.


Thanks! But it looks like you redirected it to the GitHub repo rather than
the spec itself:

$ curl -I https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
HTTP/1.1 302 Found
Date: Wed, 04 Feb 2015 07:34:26 GMT
Server: Apache/2.2.16 (Debian)
Location: http://w3c.github.io/IndexedDB/
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

Mind fixing that?

Thanks again,

--tobie

Re: [IndexedDB] link to Editor's draft is a 404

[Michael[tm] Smith]

Arthur Barstow , 2015-02-02 08:47 -0500:
> Archived-At: 
> On 2/2/15 7:14 AM, Tobie Langel wrote:
> >Heads-up that the link to the Editor's Draft of the IndexedDB spec is now
> >a 404.
> 
> Thanks for reporting this Tobie. I've asked Joshua and Mike Smith to address
> this problem.
> 
> >Not sure whether that is on purpose or an accident.
> 
> This is a side effect of moving this spec to Github:
> 
> repo: 
> ED: 
> 
> >Would recommend redirecting to the ED of the next version of the spec.
> 
> That makes sense to me.

Yup, sorry about thatーI forgot a step when we migrated the repos. But I've
now set up the redirects and things should be working as expected. If not
lemme know.

  --Mike

-- 
Michael[tm] Smith https://people.w3.org/mike


signature.asc
Description: PGP signature

Re: Minimum viable custom elements

[Ryosuke Niwa]

> On Feb 3, 2015, at 7:13 AM, Chris Bateman  wrote:
> 
> Why don't we just make all input elements support these new attributes we're 
> adding?
> 
> In my opinion, I'd say because you can't possibly cover every case - what 
> about doing the same kind of formatting for social security numbers, credit 
> card numbers, phone numbers, or who knows what else? How about other kinds of 
> functionality - like a  that automatically resizes itself?

That sounds like a slightly different use case. Social security number, credit 
card number, etc… seems like a different input type to me while "numerals" or 
"radix" attributes are extra configurations/options each input type may 
respect.  While I agree allowing author defined input types will be useful, I'm 
not certain having two different mechanisms, namely "type" and "is" attributes, 
to specify the type of an input an element expects is a desirable approach.

> What kind of initializations does it have to do? 
> 
> Yes, probably just adding a listener in this case – which you certainly could 
> handle with event delegation. But maybe someone might want to simply execute 
> some functionality when the element is created or attached. An input that 
> automatically populates itself with a random number. An awful, contrived 
> example for sure - but it wouldn't be possible with delegation alone.
> 
> Again - simply wanted to make the point that devs do add functionality to 
> native elements - so it might be handy to have custom element callbacks to 
> assist with it.

That sounds rather hypothetical to me.  I would like to know a concrete use 
case in which the initialization of an author defined input type or an input 
configuration/option is impossible or too cumbersome to be implemented using 
existing API.

Adding a new feature to the Web platform incurs an inherently higher cost 
because multiple vendors have to coordinate, and removing or changing the 
behavior of a feature is virtually impossible.

- R. Niwa

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell  wrote:

>
>
> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay  wrote:
>
>> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>>
>>> Brian recently posted what looks like an excellent framing of the
>>> composition problem:
>>>
>>> https://briankardell.wordpress.com/2015/01/14/
>>> friendly-fire-the-fog-of-dom/
>>>
>>> This is the problem we solved with Shadow DOM and the problem I would
>>> like to see solved with the primitive being discussed on this thread.
>>>
>>>
>>
>> random comments about that blog post.
>
>
>
>> [snip]
>> We need to be able to select mount nodes explicitly, and perhaps
>> explicitly say that all such nodes should be selected.
>> So, maybe, deep(mountName) and deep(*)
>>
>> Is there a reason you couldn't do that with normal CSS techniques, no
> additional combinator?  something like /mount/[id=foo] ?
>

That's ::shadow in the scoping spec:
http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement


>
>
> [snip]
>
>> "It still needs to be possible from the hosting page to say “Yes, I mean
>> all buttons should be blue”"
>> I disagree with that. It can very well be possible that some component
>> really must control the colors itself. Say, it uses
>> buttons to indicate if traffic light is red or green. Making both those
>> buttons suddenly blue would break the whole concept of the
>> component.
>>
>
This is still possible, and works in a predictable way with today's styling
machinery. Use inline styles on the button that you want to be green/red
inside of the scope, and no /deep/ or /mount/ or >>> will be able to affect
it: http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the
war progressed to the stage where "!important" is used as hammer.

:DG<

Re: Minimum viable custom elements

[Chris Bateman]

>
> Why don't we just make all input elements support these new attributes
> we're adding?


In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social security numbers, credit
card numbers, phone numbers, or who knows what else? How about other kinds
of functionality - like a  that automatically resizes itself?

What kind of initializations does it have to do?


Yes, probably just adding a listener in this case – which you certainly
could handle with event delegation. But maybe someone might want to simply
execute some functionality when the element is created or attached. An
input that automatically populates itself with a random number. An awful,
contrived example for sure - but it wouldn't be possible with delegation
alone.

Again - simply wanted to make the point that devs do add functionality to
native elements - so it might be handy to have custom element callbacks to
assist with it.

Chris



On Mon, Feb 2, 2015 at 9:40 PM, Ryosuke Niwa  wrote:

>
> On Jan 31, 2015, at 10:40 AM, Chris Bateman  wrote:
>
> The -webkit-appreance CSS is definitely another issue, so here's an
> example with just JS behavior:
>
> 
>
> This component would only allow numeric input, and insert decimals,
> commas, etc. Let's just assume that devs want to do this kind of thing.
> Here's an example I found of a such behavior:
> http://opensource.teamdf.com/number/examples/demo-as-you-type.html
>
>
> Thanks for a great use case.  I think this is a problem we should solve
> one way or another but I’m not convinced custom elements is the best
> solution for the problem at hand.
>
> If we accept that being able to specify the number of decimal points is a
> valid use case, I hope we can all agree that being able to specify the
> radix or the base of the number is also a valid use case.  Suppose we
> authors should be able to specify this with attribute "radix" where its
> value is any natural number between 1 and 15.  If we follow the school of
> thought in your proposal, then we would either add
> is="number-with-radix-input" (case A) or make "number-input" support both
> support "decimals" and "radix" attributes (case B).
>
> Case A: In this case, we quickly run into a combinatorial explosion.  As
> we add k new attributes to support, we would need 2^k elements in order to
> support every combination.  But this is silly because it's okay for authors
> to not use attributes supported by an element.  This brings us to case B.
>
> Case B: If we accept that we should create a single element that supports
> all extensions, then why do we use "is" attribute at all?  Why don't we
> just make all input elements support these new attributes we're adding?
>
> The best thing you get from using a Custom Element here is the component's
> ability to automatically initialize (and destroy) itself. If it's inserted
> into the page dynamically (via AJAX, templates in a SPA, or whatever), it
> just sets itself up.
>
>
> What kind of initializations does it have to do?  It seems like all the
> component has to do is to listen to the event listener, in addition to
> potentially sanitizing the value  if the original value had more than two
> decimal points.
>
> If JS fails, you've still got an input. It was succinct and easy to set
> up. And if the app wants to get or set the value, it just does it the same
> way it always interfaces with an input.
>
>
> Indeed the fallback scenario is very interesting here but again, it seems
> like there is no reason to use "is" attribute at all.  We can just extend
> all input elements by attaching event listeners, etc...
>
> - R. Niwa
>
>

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay  wrote:

> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>
>> Brian recently posted what looks like an excellent framing of the
>> composition problem:
>>
>> https://briankardell.wordpress.com/2015/01/14/
>> friendly-fire-the-fog-of-dom/
>>
>> This is the problem we solved with Shadow DOM and the problem I would
>> like to see solved with the primitive being discussed on this thread.
>>
>>
>
> random comments about that blog post.



> [snip]
> We need to be able to select mount nodes explicitly, and perhaps
> explicitly say that all such nodes should be selected.
> So, maybe, deep(mountName) and deep(*)
>
> Is there a reason you couldn't do that with normal CSS techniques, no
additional combinator?  something like /mount/[id=foo] ?


[snip]

> "It still needs to be possible from the hosting page to say “Yes, I mean
> all buttons should be blue”"
> I disagree with that. It can very well be possible that some component
> really must control the colors itself. Say, it uses
> buttons to indicate if traffic light is red or green. Making both those
> buttons suddenly blue would break the whole concept of the
> component.
>

By the previous comment though it seems you are saying it's ok to reach
into the mounts, in which case you could do exactly this... Perhaps the
shortness of the sentence makes it seem like I am saying something I am
not, basically I'm saying it should be possible to explicitly write rules
which do apply inside a mount.  CSS already gives you all sorts of tools
for someone developing a bit in isolation to say how important it is that
this particular rule holds up - you can increase specificity with id-based
nots or use !important or even the style attribute itself if it is that
fundamental - what you can't do is protect yourself on either end from
accidental error.  I feel like one could easily over-engineer a solution
here and kill its actual chances of success, whereas a smaller change could
not only have a good chance of getting done, but have very outsized impact
and provide some of the data on how to improve it further.  If this doesn't
seem -hostile- to decent further improvements, finding something minimal
but still very useful might be good.




>
>
> -Olli
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com

PSA: publishing new WD of Service Workers on February 5

[Arthur Barstow]

The Service Workers editors - which now includes Jake Archibald (thanks 
Jake!) - would like to publish a new WD of Service Workers and the 
proposed publication date is February 5:




If anyone has any major concerns with this, please speak up immediately; 
otherwise the WD will be published as proposed.


-Thanks, ArtB

RE: IndieUI Teleconference Agenda; 4 February at 22:00Z for 60 minutes

[Katie Haritos-Shea GMAIL]

Possible regrets overseas



* katie *
 
Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryla...@gmail.com | Oakton, VA | LinkedIn Profile |
Office: 703-371-5545

-Original Message-
From: Janina Sajka [mailto:jan...@rednote.net] 
Sent: Monday, February 2, 2015 11:31 PM
To: public-indie...@w3.org
Cc: public-editing...@w3.org; public-webapps@w3.org
Subject: IndieUI Teleconference Agenda; 4 February at 22:00Z for 60 minutes

Cross-posting as is now usual ...

What:   IndieUI Task Force Teleconference
When:   Wednesday 4 February
 2:00 PMSan Francisco -- U.S. Pacific  Time (PST: UTC
-8)
 4:00 PMAustin -- U.S. Central  Time(CST: UTC
-6)
 5:00 PMBoston -- U.S. Eastern  Time(EST: UTC
-5)
10:00 PMLondon -- British  Time (BST: UTC +0)
11:00 PMParis -- Central European Time  (CET: UTC
+1)
 6:00 AMBeijing -- China Standard Time  (Thursday, 13
November CST: UTC +8)
 7:00 AMTokyo -- Japan Standard Time(Thursday, 13
November JST: UTC +9)
Where:  W3C Teleconference--See Below

* Time of day conversions

Please verify the correct time of this meeting in your time zone using the
Fixed Time Clock at:

http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconference&;
iso=20150204T1700&p1=43&ah=1

** Preliminary Agenda for IndieUI Task Force Teleconference 4 February 2015

Meeting: IndieUI Task Force Teleconference
Chair:  Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+ Checkin with Web Apps' Editing TF [See below]  Editors' Reports
agenda+ User Context Progress
agenda+ User Context Issues & Actions 
agenda+https://www.w3.org/WAI/IndieUI/track/products/3
agenda+ Events Issues & Actions
https://www.w3.org/WAI/IndieUI/track/products/2
agenda+  Other Business
agenda+ Be Done

Resource: TPAC Minutes
Monday: http://www.w3.org/2014/10/27-indie-ui-minutes.html  
Tuesday:http://www.w3.org/2014/10/28-indie-ui-minutes.html

Resource: Teleconference Minutes
http://www.w3.org/2015/01/21-indie-ui-minutes.html

Resource: Web Apps Editing TF
Editing Explainer:  http://w3c.github.io/editing-explainer/
User Intentions:
http://w3c.github.io/editing-explainer/commands-explainer.html
 
Resource: For Reference
Home Page:  http://www.w3.org/WAI/IndieUI/
Email Archive:  http://lists.w3.org/Archives/Public/public-indie-ui/

Resource: Teleconference Logistics
Dial the Zakim bridge using either SIP or the PSTN.
PSTN: +1.617.761.6200 (This is a U.S. number).
SIP: za...@voip.w3.org
You should be prompted for a pass code,
This is
46343#
(INDIE#)

Alternatively, bypass the Zakim prompts and SIP directly into our
teleconference.
SIP: 0046...@voip.w3.org

Instructions for connecting using SIP:
http://www.w3.org/2006/tools/wiki/Zakim-SIP
Place for users to contribute additional VoIP tips.
http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips

IRC: server: irc.w3.org, channel: #indie-ui.

During the conference you can manage your participation with Zakim commands
as follows:
61# to mute yourself
60# to unMute yourself
41# to raise your hand (enter speaking queue)
40# to lower your hand (exit speaking queue)

The system acknowledges these commands with a rapid, three-tone
confirmation.  Mobile phone users especially should use the mute function if
they don't have a mute function in their phone.  But the hand-raising
function is a good idea for anyone not using IRC.

* IRC access

An IRC channel will be available. The server is irc.w3.org, The port number
is 6665 (Note this is not the normal default) and The channel is #indie-ui.

* Some helpful Scribing and Participation Tips
http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet

For more on the IRC setup and the robots we use for agenda and speaker
queuing and for posting the log to the web, see:

- For RRSAgent, that captures and posts the log with special attention to
action items:
http://www.w3.org/2002/03/RRSAgent

- For Zakim, the IRC interface to the bridge manager, that will maintain
speaker and agenda queues:
http://www.w3.org/2001/12/zakim-irc-bot

- For a Web gateway to IRC you can use if your network administrators forbid
IRC, see:
http://www.w3.org/2001/01/cgi-irc

- For more on W3C use of IRC see:
http://www.w3.org/Project/IRC/

-- 

Janina Sajka,   Phone:  +1.443.300.2200
sip:jan...@asterisk.rednote.net
Email:  jan...@rednote.net

The Linux Foundation
Chair, Open Accessibility:  http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,  Protocols & Formats http://www.w3.org/wai/pf
IndieUI http://www.w3.org/WAI/IndieUI/

Re: Shadow tree style isolation primitive

[Olli Pettay]

On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:

Brian recently posted what looks like an excellent framing of the composition 
problem:

https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/

This is the problem we solved with Shadow DOM and the problem I would like to 
see solved with the primitive being discussed on this thread.




random comments about that blog post.

"Its intuitive then to create a combinator in CSS which allows you to select the 
mount explicitly"
Yes, I agree with that assuming the mount actually wants to be selectable.
And even if all the mounts were selectable, we don't have atm a way to select 
some particular
mount explicitly. And I think we should have that explicitly-ness. >>> or 
/deep/ are like
select all and cross your fingers you selected what you wanted, and not 
anything more.
We need to be able to select mount nodes explicitly, and perhaps explicitly say 
that all such nodes should be selected.
So, maybe, deep(mountName) and deep(*)


"It still needs to be possible from the hosting page to say “Yes, I mean all buttons 
should be blue”"
I disagree with that. It can very well be possible that some component really 
must control the colors itself. Say, it uses
buttons to indicate if traffic light is red or green. Making both those buttons 
suddenly blue would break the whole concept of the
component.


Without the explicitly-ness we're back having the initial problems we're trying 
to solve, as the
blog says
"That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that 
aren’t “yours“. "

Same explicitly-ness should apply to things like Event.path etc.




(I still think shadow DOM needs proper encapsulation, even if components would 
all be 'allies'. A use case for encapsulation
would be rather similar to private: or protected: in many languages. But 
encapsulation is perhaps a bit different issue from
weaker isolation.)



-Olli