Standardizing autocapitalize
(bcc: public-webapps@) Hi, I would like to standardize the Apple's proprietary autocapitalize attribute. This attribute is widely used and it would probably benefit the platform to have a broader support for it. The implementation cost should be fairly low while it can be very beneficial for the user experience with the keyboard on Mobile. I wrote a small proposal document based on Apple's document and live tests on latest Safari mobile: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md I would be really interested to hear from other vendors, particularly if they would be interested to implement it. In addition, if Apple has some feedback about the proposal, it would be very valuable. Thanks, -- Mounir
template namespace attribute proposal
I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template Likewise, content should work properly inside of that template tag, but I suspect that's more of a proposal for the SVG spec. This proposal comes from work I'm doing at Netflix to create composable graph components that are SVG based. Currently, I'm not able to use template tags efficiently. This proposal seems like something that would be good in the long run, and something that would also be easy to polyfill in the meantime. What are your thoughts on this idea? Thank you, Ben Lesh @benlesh Senior UI Engineer Netflix
Re: template namespace attribute proposal
On 12/03/2015 11:07 , Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Or even go the extra mile and just slurp all SVG elements into the HTML namespace. There are a few name clashes, but we ought to be able to iron those out. And ditto MathML. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon ro...@w3.org wrote: On 12/03/2015 11:07 , Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Love this idea. Or even go the extra mile and just slurp all SVG elements into the HTML namespace. There are a few name clashes, but we ought to be able to iron those out. And ditto MathML. Not sure what the timeline would look like for this work. I guess this would depend on whether there's existing content counting on namespaces being different? :DG
Re: CfC: publish WG Note of UI Events; deadline November 14
Hi All, This CfC (original thread is [1]) is now moving forward and on March 17 there will be two publications: 1. /UI Events (Keyboard Extension)/; W3C Working Group Note; (draft is http://jay.w3.org/~plehegar/uievents-ext.html). 2. /UI Events Specification (formerly DOM Level 3 Events)/; W3C Working Draft; (draft is http://jay.w3.org/~plehegar/uievents.html). The following redirects will also be made: 1. http://www.w3.org/TR/DOM-Level-3-Events/ will redirect to http://www.w3.org/TR/uievents/. 2. http://www.w3.org/TR/uievents/ will redirect to http://www.w3.org/TR/2015/WD-uievents-20150317/. -Regards, ArtB [1] https://lists.w3.org/Archives/Public/www-dom/2014OctDec/0039.html On 11/7/14 10:28 AM, Arthur Barstow wrote: During WebApps' October 27 meeting, the participants agreed to stop work on the UI Events spec and to publish it as a WG Note (see [Mins]). As such, this is a formal Call for Consensus (CfC) to: a) Stop work on this spec b) Publish a gutted WG Note of the spec; see [Draft-Note] c) Gut the ED (this will be done if/when this CfC passes) d) Prefix the spec's [Bugs] with HISTORICAL and turn off creating new bugs e) Travis will move all bugs that are relevant to D3E to the D3E bug component Note Action-734 resulted in a discussion about the rationale for this proposal ([Discuss]). If anyone has comments or concerns about this CfC, please reply by November 14 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. In the absence of any non-resolvable issues, I will see make sure the Note is published. -Thanks, AB [Mins] http://www.w3.org/2014/10/27-webapps-minutes.html#item05 [Draft-Note] https://dvcs.w3.org/hg/d4e/raw-file/default/tr.html [Bugs] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=UI%20Eventsresolution=--- [Discuss] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0262.html
Re: template namespace attribute proposal
FWIW: Currently, template tags nested in svg are SVGElement, and not HTMLTemplate Element. You also need to hide the SVG container or it will be rendered. On Mar 12, 2015 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa rn...@apple.com wrote: By special casing, do you mean to recognize SVG element names? Yeah, not really sure there's another way of doing it. (You can of course put things within svg, but then you could also put tbody in table...) I'd prefer allowing template elements inside SVG as in: svgtemplate~/template/svg Would that create an HTMLTemplateElement with a different parser mode? -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa rn...@apple.com wrote: By special casing, do you mean to recognize SVG element names? Yeah, not really sure there's another way of doing it. (You can of course put things within svg, but then you could also put tbody in table...) I'd prefer allowing template elements inside SVG as in: svgtemplate~/template/svg Would that create an HTMLTemplateElement with a different parser mode? -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein ad...@chromium.org wrote: For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. That was going to be my argument, but then I remembered that we went out of our way to make tbody, tr, td, etc. work as direct children of template. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein ad...@chromium.org wrote: For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. That was going to be my argument, but then I remembered that we went out of our way to make tbody, tr, td, etc. work as direct children of template. Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere?
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein ad...@chromium.org wrote: Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere? It was more principled, not sure about compatibility. Most of the HTML parser depends on modes. Then requiring svg makes sense. Just like it makes sense to require table for td not to be dropped. However, template was designed to work with any element, irrespective of mode. So td should work without table anywhere. Following that logic, it would make sense if circle worked without svg anywhere. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh bl...@netflix.com wrote: I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. - Adam
RE: template namespace attribute proposal
I would also prefer to enable this to work without any extra annotation. So much of the rest of how SVG/MathML are handled in HTML is seamless by design. From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein Sent: Thursday, March 12, 2015 11:17 AM To: Benjamin Lesh Cc: WebApps WG Subject: Re: template namespace attribute proposal On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh bl...@netflix.commailto:bl...@netflix.com wrote: I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. - Adam
[Shadow] URL-based shadows?
Dimitri et al., Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of micro-import or an import that parses its document directly into the ShadowRoot container?) I'm curious to know if there's some obvious flaw that I'm missing. element.createShadowRoot(path to my component); This is an idea around building components from the inside out, and using the URL as the basis for script-level access control to the Shadow contents. Thoughts?
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
So much of the rest of how SVG/MathML are handled in HTML is seamless by design. For my part, I disagree slightly with this statement. If you just drop a circle tag in a div, you're going to get an HTMLUnknownElement. This is by design and to spec, of course. But it unfortunately means you can't clone() the element over to an SVG parent and hope it will work. This was a problem in Angular's $compile that I helped sort out. Angular would simple clone() partials straight from the DOM and insert them, if that partial happened to be some fragment of SVG, you were then sticking HTMLUnknownElements in your SVG Doc. Ultimately, Angular ended up tracking namespace changes as it traversed the DOM looking for directives, as well as specifying a starting namespace for directives with template strings that were SVG partials. Ember and Handlebars had similar issues with this. Handlebars had to use a wrapMap technique to create DOM elements in the proper way, but that didn't account for the a tag which exists in both namespaces. I'm not sure what HTMLBars is doing to solve this problem, honestly. I'd be shocked if whatever they were doing didn't require some sort of namespace specification somewhere, or simply didn't work with certain edge cases like the a tag. I think this feature is really something that will help framework developers and component library developers create generic code to accommodate their needs. It's more for code sanity than anything. templatesvgcircle//svg/template will clearly work, but then you're putting the onus on the framework authors to make conditional checks that might not always be accurate is the firstElementNode svg? If I'm a framework author, I can't dependably check that and just assume it's an SVG partial. It could be a full SVG-based web component. On Thu, Mar 12, 2015 at 2:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein ad...@chromium.org wrote: Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere? It was more principled, not sure about compatibility. Most of the HTML parser depends on modes. Then requiring svg makes sense. Just like it makes sense to require table for td not to be dropped. However, template was designed to work with any element, irrespective of mode. So td should work without table anywhere. Following that logic, it would make sense if circle worked without svg anywhere. -- https://annevankesteren.nl/
Re: [Shadow] URL-based shadows?
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly received (can't remember the details). :DG On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead travis.leith...@microsoft.com wrote: Dimitri et al., Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of “micro-import” or an import that parses its document directly into the ShadowRoot container?) I’m curious to know if there’s some obvious flaw that I’m missing. element.createShadowRoot(“path to my component”); This is an idea around building components from the “inside out”, and using the URL as the basis for script-level access control to the Shadow contents. Thoughts?
