Re: Shadow tree style isolation primitive
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. :DG
Toward more productive f2f meetings [Was:Re: Feedback needed for April 2015 face-to-face location by *January 27, 2015*]
On 1/20/15 5:38 PM, Philippe Le Hegaret wrote: We are fortunate enough to have two proposed locations for the HTML and Web Applications face-to-face meeting in the week of April 13-17, 2015. Your feedback will help us picking the location. 1. Redmond, WA, USA (Hosted by Microsoft): 2. Zaragoza, Spain (Hosted by Yandex) Please provide your preferences at: https://www.w3.org/2002/09/wbs/42538/webapps-spring-2015/ by January 27, 2015. We will then try to make sense out of the input and pick the location. Hi All, As you can see from the results at [1] and [2], there is no dominant preference for either location. One option to determine the winner is to re-open the survey to try to get additional data (and there could be other options). I'd like to take this as an opportunity to step back a bit and to discuss: what is the value proposition of WebApps' f2f meetings; how to maximize the usefulness of f2f meetings; how to make f2f meetings more productive. All feedback is welcome! My current thinking is two-fold. First, I think we should continue to have a f2f meeting during the annual TPAC all group meeting week. This would help satisfy what I would characterize as the geographical equalizer meeting requirement. (If anyone finds that term offensive, I apologize. I do agree with efforts to share the pain regarding travel time and related costs and I think the possibility for cross-group meetings at TPAC can be quite valuable.) Although f2f meetings can have a number of non-technical benefits, in general, I'm not convinced our previously used structure of a two-day meeting that touches on a broad set of the the group's 30+ specs is especially effective in solving high priority technical issues. Additionally, if the current replies for this survey are roughly equivalent to the set of people that would actually attend one of these meetings/venues, I am somewhat skeptical significant technical progress will be made regardless of the venue. Instead of a centralized broadly scoped f2f meeting, perhaps it would be more useful to have topic-specific meetings located at or near the critical mass of active contributors, and only have such a meeting if the editors and key contributors commit to participate. For example, a Web Components meeting (as was done in 2013), an Editing and Selection meeting, etc. Again, all feedback is welcome! Last, regardless of the next step, I want to thank Philippe for his effort, and Chaals and Paul Cotton for getting support to host the meeting. -Thanks, ArtB [1] https://www.w3.org/2002/09/wbs/42538/webapps-spring-2015/results [2] http://intertwingly.net/tmp/w3c-spring-2015
[IndexedDB] link to Editor's draft is a 404
Hi, Heads-up that the link to the Editor's Draft of the IndexedDB spec is now a 404. Not sure whether that is on purpose or an accident. Would recommend redirecting to the ED of the next version of the spec. Thanks, --tobie
Re: [IndexedDB] link to Editor's draft is a 404
On 2/2/15 7:14 AM, Tobie Langel wrote: Hi, 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: https://github.com/w3c/IndexedDB ED: http://w3c.github.io/IndexedDB/ Would recommend redirecting to the ED of the next version of the spec. That makes sense to me. -ArtB
Re: Minimum viable custom elements
On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn espr...@chromium.org wrote: The animation is a custom element called paper-ripple, where do you see it using -webkit-tap-highlight-color? The initial page uses that. Ryosuke's reply to this particular demo is a lot more on topic. It's not using is=. (Use of proprietary CSS features still seems bad though.) -- https://annevankesteren.nl/
Re: Minimum viable custom elements
On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman chrisb...@gmail.com wrote: The -webkit-appreance CSS is definitely another issue, so here's an example with just JS behavior: input is=number-input decimals=2 The way to do this, FWIW, is input type=number step=0.01 and solve the styling issue. -- https://annevankesteren.nl/
Re: Minimum viable custom elements
On Jan 31, 2015, at 10:40 AM, Chris Bateman chrisb...@gmail.com wrote: The -webkit-appreance CSS is definitely another issue, so here's an example with just JS behavior: input is=number-input decimals=2 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 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
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+Teleconferenceiso=20150204T1700p1=43ah=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] agenda+ Editors' Reports agenda+ User Context Progress agenda+ User Context Issues Actions 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/
