Re: Custom Element Semantics
Thanks Alex! I have made some updates to the spec text in response to your feedback, I have also added other content. http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics please review, thanks! -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 9 December 2014 at 17:29, Alexander Surkov surkov.alexan...@gmail.com wrote: Hi. Some feedback per Steve's request on WAI group. * but for the semantics to be formally expressed, developers must convey the role, states and properties of the element to browser APIs. It's not clear what role, states and properties is. It'd be good to develop this sentence by mentioning ARIA techniques. Also it might be not clear what browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info is rather for browser developers and may sound confusing for web authors. * I don't think that any focusable element should get its name from its subtree. For example, tree control name is not a concatenation of subtrees of its item. I think role should define whether the element should grab its name from the subtree or not. taco-button tabindex=0Eat Me/taco-button * The addition of a tabindex http://www.w3.org/TR/html/editing.html#attr-tabindex attribute to the *taco-button* element I think taco-button should be left for examples, but all rules should be worded in generic terms. For example, the sentence above would be The addition of tabindex attribute to the custom element and then give a markup example for taco-button. * The addition of keyboard event handlers to the *taco-button* element provides the means for keyboard users to operate the control, but does not convey the presence of the functionality. I think I miss the idea of this sentence because the topic is about semantics of custom elements and thus it's not clear with me where functionality is supposed to be here. * The addition of an ARIA role=button http://rawgit.com/w3c/aria/master/aria/aria.html#button conveys the *taco-button* element's role semantics It'd be good to generalize it and give this sentence as an example. It'd be good to mention other ARIA button related attributes. Thanks. Alexander. On Tue, Dec 9, 2014 at 4:23 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi PF! FYI I have been getting some accessibility related content into the custom elements spec http://w3c.github.io/webcomponents/spec/custom/#semantics please provide feedback on bug https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=14968short_desc=[Custom]%3A%20product=WebAppsWGcomponent=Component%20Model or to webapps list http://lists.w3.org/Archives/Public/public-webapps/ -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
[Bug 27597] [Shadow]: ShadowRoot is an interface (change section title)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27597 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hayato Ito hay...@chromium.org --- Thanks. This should be fixed in: https://github.com/w3c/webcomponents/commit/c6c7a579542a42d9a407ef161b96cab9a8002e7a -- You are receiving this mail because: You are on the CC list for the bug.
Re: PSA: publishing new WD of Custom Elements on December 16
Hi Art, I don't have any objection to publishing as is. Would like to note that I have pretty much completed the first draft of the custom element semantics stuff now http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics and have filed a pull request https://github.com/w3c/webcomponents/pull/29 to merge the additions. There is a merge conflict tried to work it out but my git fu is lacking :-( -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 11 December 2014 at 01:10, Arthur Barstow art.bars...@gmail.com wrote: Dimitri prepared a new Working Draft of Custom Elements for publication on December 16: http://w3c.github.io/webcomponents/publish/custom/ WD-custom-elements-20141218/ If anyone has any major concerns about this proposal, please speak up. -Thanks, AB
[Bug 27611] New: [Custom]: SVG diagram accessibility
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27611 Bug ID: 27611 Summary: [Custom]: SVG diagram accessibility Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: faulkner.st...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 Appendix A: All Algorithms in One Diagram the svg Diagram is not accessible, will look into making it so. -- You are receiving this mail because: You are on the CC list for the bug.
Re: PSA: publishing new WD of Custom Elements on December 16
On 12/15/14 6:00 AM, Steve Faulkner wrote: Hi Art, I don't have any objection to publishing as is. Would like to note that I have pretty much completed the first draft of the custom element semantics stuff now http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics and have filed a pull request https://github.com/w3c/webcomponents/pull/29 to merge the additions. There is a merge conflict tried to work it out but my git fu is lacking :-( OK, thanks for the update. A new WD is already `staged` to be published on December 16. As such, we'll have to wait until next year to include any additional changes. (If desired, perhaps this spec can be included in the `allow automatic of WDs in /TR` mechanism that will be implemented in January http://lists.w3.org/Archives/Public/public-openw3c/2014Dec/0001.html). -Thanks, ArtB
HTML imports in Firefox
I was a little surprised to read Mozilla don't plan on shipping HTML imports and will re-evaluate after modules are supported: https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ Why would modules affect the decision to ship HTML imports? Imports get you: - the ability to import style and markup, not just script - a tree-like dependency structure with automatic deduplication - parallel loading/parsing - ability to start fetching sub-resources before script has parsed and run - tidy markup (sub-resources go in their import documents, not all dumped in to head) I don't see how modules has any impact on this. In a web environment where components will commonly use style, templates and the like, imports seem like the obvious choice over modules. The webcomponents.org polyfill for imports has a couple of caveats, so it doesn't look like it's totally equivalent and portable with browsers with native support, like Chrome which has shipped it already. I'm keen to see Mozilla ship this feature too. Ashley
Re: HTML imports in Firefox
On 12/15/14, 1:10 PM, Ashley Gullen wrote: Why would modules affect the decision to ship HTML imports? Because the interaction of the various import systems with each other needs to be specified, for one thing. But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. The webcomponents.org http://webcomponents.org polyfill for imports has a couple of caveats, so it doesn't look like it's totally equivalent and portable with browsers with native support, like Chrome which has shipped it already. Chrome has shipped a lot of things in this space already. Feel free to mail me privately for my feelings on the matter. chrome shipping something is not sufficient reason to ship something we're pretty sure is deficient, I'm afraid. -Boris
Re: HTML imports in Firefox
On 12/15/14 2:09 PM, Boris Zbarsky wrote: On 12/15/14, 1:10 PM, Ashley Gullen wrote: Why would modules affect the decision to ship HTML imports? Because the interaction of the various import systems with each other needs to be specified, for one thing. But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. Hi Boris, Does [Bugzilla] capture all of Mozilla's Imports concerns (or at least the higher priority issues)? If not, who should I contact to request capturing your concerns? (It appears you have participated in two Imports bugs [BZ].) -Thanks, ArtB [Bugzilla] https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Component%20Modellist_id=49215product=WebAppsWGquery_format=advancedshort_desc=%5BImports%5Dshort_desc_type=allwordssubstr [BZ] https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Component%20Modelemail1=bzbarsky%40mit.eduemailassigned_to1=1emailcc1=1emaillongdesc1=1emailqa_contact1=1emailreporter1=1emailtype1=substringlist_id=49216product=WebAppsWGquery_format=advancedshort_desc=%5BImports%5Dshort_desc_type=allwordssubstr
Re: HTML imports in Firefox
On Mon, Dec 15, 2014 at 9:09 PM, Arthur Barstow art.bars...@gmail.com wrote: Does [Bugzilla] capture all of Mozilla's Imports concerns (or at least the higher priority issues)? If not, who should I contact to request capturing your concerns? The high-order bit is that Mozilla is not interested in shipping anything here until 1) ES6 modules have been adopted and 2) people have used that to create dependency systems in libraries and frameworks. We have already committed to two systems (ES6 modules and service workers) that heavily impact this space. Given that those working on ES6 modules do not think HTML Imports is a good match and HTML Imports can be polyfilled to the extent necessary to make use of custom elements (as seen in e.g. Gaia), we don't think it's needed at this point. -- https://annevankesteren.nl/
Re: HTML imports in Firefox
On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu wrote: But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. Well, imports work better for us than Javascript modules, for the reasons I gave. I hadn't given any feedback because everything looked great with HTML imports and I was simply waiting for it to arrive in browsers. Maybe the process biases feedback towards the negative? I guess you never hear the chorus of cool, can't wait! from everyone looking forwards to it? On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/14, 1:10 PM, Ashley Gullen wrote: Why would modules affect the decision to ship HTML imports? Because the interaction of the various import systems with each other needs to be specified, for one thing. But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. The webcomponents.org http://webcomponents.org polyfill for imports has a couple of caveats, so it doesn't look like it's totally equivalent and portable with browsers with native support, like Chrome which has shipped it already. Chrome has shipped a lot of things in this space already. Feel free to mail me privately for my feelings on the matter. chrome shipping something is not sufficient reason to ship something we're pretty sure is deficient, I'm afraid. -Boris
Re: HTML imports in Firefox
Very generally: this is actually why I said way back that a lot of things seem like prollyfills (we hope that's the future) rather than polyfills (it's a done deal) and advocated we make sure it's a future-safe, forward compatible approach. On Dec 15, 2014 4:06 PM, Ashley Gullen ash...@scirra.com wrote: On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu wrote: But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. Well, imports work better for us than Javascript modules, for the reasons I gave. The p(r)olyfill is actually pretty decent and not huge, smaller than a lot of module loaders. For such an integral kind of platform feature, if we have a fairly nice polyfill and things are potentially still debatable and there are legit seeming wants that aren't met, why not use it? I hadn't given any feedback because everything looked great with HTML imports and I was simply waiting for it to arrive in browsers. Maybe the process biases feedback towards the negative? I guess you never hear the chorus of cool, can't wait! from everyone looking forwards to it? Currently, I agree, some of us are working on that so that we tighten the feedback loop with both positive and negative feedback without overwhelming the system. On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/14, 1:10 PM, Ashley Gullen wrote: Why would modules affect the decision to ship HTML imports? Because the interaction of the various import systems with each other needs to be specified, for one thing. But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. The webcomponents.org http://webcomponents.org polyfill for imports has a couple of caveats, so it doesn't look like it's totally equivalent and portable with browsers with native support, like Chrome which has shipped it already. Chrome has shipped a lot of things in this space already. Feel free to mail me privately for my feelings on the matter. chrome shipping something is not sufficient reason to ship something we're pretty sure is deficient, I'm afraid. -Boris
Re: HTML imports in Firefox
Ashley Gullen wrote: On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need solved. We'd prefer to not ship imports and then need to ship yet another HTML import system that solves those problems. Well, imports work better for us than Javascript modules, for the reasons I gave. I hadn't given any feedback because everything looked great with HTML imports and I was simply waiting for it to arrive in browsers. Maybe the process biases feedback towards the negative? No, rather a Chrome-only writte-in-C++ specification by implementation is, however nice you find it, underspecified. I guess you never hear the chorus of cool, can't wait! from everyone looking forwards to it? Let's work through interop issues with the polyfill, first, please. /be
RE: DOM L3 Events Input Events Work to the Editing Task Force
On Mon, Dec 8, 2014 at 2:33 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: [...] Thus, I wonder if a separate Input Event spec (that both D3E and Editing would refer to) would make more sense. I think so. I have started that spec at http://w3c.github.io/editing-explainer/input-events.html.
Re: HTML imports in Firefox
On 12/15/14, 3:09 PM, Arthur Barstow wrote: Does [Bugzilla] capture all of Mozilla's Imports concerns (or at least the higher priority issues)? Not yet. We've just gotten things sorted out on our end. If not, who should I contact to request capturing your concerns? I think Anne's email covers it. -Boris
