Standardizing autocapitalize

[Mounir Lamouri]

(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

[Benjamin Lesh]

I'd like to propose that the  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.:

http://www.w3.org/2000/svg>
  



Likewise,  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
 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

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh  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 -parsing logic is set up so
that things work without special effort.


-- 
https://annevankesteren.nl/

Re: template namespace attribute proposal

[Robin Berjon]

On 12/03/2015 11:07 , Anne van Kesteren wrote:

On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh  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 -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: CfC: publish WG Note of UI Events; deadline November 14

[Arthur Barstow]

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 
).


2. /UI Events Specification (formerly DOM Level 3 Events)/; W3C Working 
Draft; (draft is ).


The following redirects will also be made:

1.  will redirect to 
.


2.  will redirect to 
.


-Regards, ArtB

[1] 


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=WebAppsWG&component=UI%20Events&resolution=---
[Discuss] 
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0262.html

Re: template namespace attribute proposal

[Dimitri Glazkov]

On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon  wrote:

> On 12/03/2015 11:07 , Anne van Kesteren wrote:
>
>> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh  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 -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: template namespace attribute proposal

[Ryosuke Niwa]

> On Mar 12, 2015, at 4:13 AM, Robin Berjon  wrote:
> 
>> On 12/03/2015 11:07 , Anne van Kesteren wrote:
>>> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh  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 -parsing logic is set up so
>> that things work without special effort.

By special casing, do you mean to recognize SVG element names?

I'd prefer allowing template elements inside SVG as in:
~

> 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.

I don't think we can make that change without breaking backwards compatibility.

- R. Niwa

Re: template namespace attribute proposal

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa  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 , but then you could also put  in
...)


> I'd prefer allowing template elements inside SVG as in:
> ~

Would that create an HTMLTemplateElement with a different parser mode?


-- 
https://annevankesteren.nl/

Re: template namespace attribute proposal

[Benjamin Lesh]

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"  wrote:

> On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa  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 , but then you could also put  in
> ...)
>
>
> > I'd prefer allowing template elements inside SVG as in:
> > ~
>
> Would that create an HTMLTemplateElement with a different parser mode?
>
>
> --
> https://annevankesteren.nl/
>

Re: template namespace attribute proposal

[Adam Klein]

On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh  wrote:

> I'd like to propose that the  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.:
>
> http://www.w3.org/2000/svg>
>   
> 
>

For clarity, is this significantly different from the below (which works
today)?


  

  


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

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein  wrote:
> For clarity, is this significantly different from the below (which works
> today)?
>
> 
>   
> 
>   
> 
>
> 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 , , , etc. work as direct
children of .


-- 
https://annevankesteren.nl/

RE: template namespace attribute proposal

[Travis Leithead]

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 
mailto:bl...@netflix.com>> wrote:
I'd like to propose that the  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.:

http://www.w3.org/2000/svg>
  


For clarity, is this significantly different from the below (which works today)?


  

  


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

[Adam Klein]

On Thu, Mar 12, 2015 at 11:22 AM, Anne van Kesteren 
wrote:

> On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein  wrote:
> > For clarity, is this significantly different from the below (which works
> > today)?
> >
> > 
> >   
> > 
> >   
> > 
> >
> > 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 , , , etc. work as direct
> children of .
>

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  has fewer compat risks than a wholesale change of the
HTML parser to recognize SVG-looking tags anywhere?

Re: template namespace attribute proposal

[Anne van Kesteren]

On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein  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  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  makes sense. Just like
it "makes sense" to require  for  not to be dropped.
However,  was designed to work with any element,
irrespective of mode. So  should work without  anywhere.
Following that logic, it would make sense if  worked without
 anywhere.


-- 
https://annevankesteren.nl/

Re: template namespace attribute proposal

[Benjamin Lesh]

> 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  tag in a , 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  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  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.

 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  wrote:

> On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein  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  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  makes sense. Just like
> it "makes sense" to require  for  not to be dropped.
> However,  was designed to work with any element,
> irrespective of mode. So  should work without  anywhere.
> Following that logic, it would make sense if  worked without
>  anywhere.
>
>
> --
> https://annevankesteren.nl/
>

[Shadow] URL-based shadows?

[Travis Leithead]

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: [Shadow] URL-based shadows?

[Dimitri Glazkov]

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?
>