Re: Meeting between Web platform and ARIA at TPAC

[Brian Kardell]

On Thu, Aug 4, 2016 at 10:00 AM, Rich Schwerdtfeger 
wrote:

> Leonie, Charles,
>
> I would like to request a 90 minute meeting on Friday at TPAC. Of critical
> importance is the discussion regarding the requirements around Web
> Components. Some issues I know we need to discuss are:
>
> 1. ARIA 2.0 extensibility
> 2. ARIA  2.0 needed semantics
> 3. Ability to reference elements inside a web component and from within
> the web component to outside the web component.
>
> Best,
> Rich
>
> Rich Schwerdtfeger
>
>
I'll be at TPAC and would really love to be there for this if that is
possible.

-- 
Brian Kardell :: @briankardell

Re: [custom-elements] Prefix x- for custom elements like data- attributes

[Brian Kardell]

On Mon, Apr 25, 2016 at 1:06 PM, Bang Seongbeom 
wrote:

> It would be good to restrict custom element's name to start with like
> 'x-' for the future standards. User-defined custom attributes; data
> attributes are also restricted its name to start with 'data-' so we can
> define easily new standard attribute names ('aria-*' or everything
> except for 'data-*'.)
>

You can't really reasonably further restrict future HTML though.  Relaxing
it is easier than restricting it.  I can't really really understand why
you'd want to in this case as they are dasherized.  HTML doesn't need
dasherized native elements.

In practice attributes aren't really restricted either - there is a
veritable ocean of custom attributes out there that are not data-*
prefixed.  data-* attributes do give you a potentially nicer API for
dealing with attribute-oriented properties.  Things like angular used ng-*
and, realistically, those are probably safe.  It's not likely that html
needs those in the future.   They've also done some interesting things at
looking at what is actually functionally valid - like attribute names that
are surrounded by braces or parens.  In any case, since people are well
aware that they -can- use any old attributes, it kind of doesn't matter
what the spec says when it comes to new standards.  If it would break the
web, it would break the web.

Same with custom tags really, HTML has always permitted them because that's
how it is forward parsable... But they haven't had a way to be useful.
Custom elements, make them useful, but put them in a compelling box that
allow us to add anything that isn't dasherized.  That was a long long long
way in the making, I can't honestly see it being undone in an even stricter
fashion.



-- 
Brian Kardell :: @briankardell

Re: [Custom Elements] Extension of arbitrary elements at runtime.

[Brian Kardell]

On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea  wrote:

> The is="" attribute lets one specify that some element is actually an
> extended version of that element.
>
> But, in order for this to work, the Custom Element definition has to
> deliberately extend that same basic element type or else it won't
> work.
>
> It'd be nice if a Custom Element definition could be arbitrarily
> applied to any type of element, with the is="" tag for example, and
> that the element would then be upgraded to the extending type at
> runtime. The custom element could be told what class it is extending
> at runtime in order to perhaps act differently using conditional
> statements.
>
> So, writing defining the element could be like this:
>
> ```js
> let isDynamic = true
> document.registerElement('some-element', {
>   createdCallback: function() {
> if (this.typeExtended == 'DIV")
>   // ...
> if (this.typeExtended == 'BUTTON')
>   // ...
>   },
> }, isDynamic)
> ```
>
> then using the element could be like this:
>
> ```html
> 
> 
> 
> ```
>
> What are your thoughts on such a way to extend any type of element at
> runtime? Could it be a way for augmenting, for example, an existing
> app without necessarily having to modify it's markup, just simply
> adding is="" attributes as needed? Would this make things too
> complicated?
>
> The real reason I thought of this idea is because:
> https://github.com/infamous/infamous/issues/5
>
> There might be a better way, but thought I'd mention it just in case
> it sparks any ideas.
>
> Cheers!
> - Joe
>
> /#!/JoePea
>
>

Is there a reason that you cannot wrap with fallback?  For example, in your
github issue you are given and existing app with markup like:


  
Hello
  


and the issue wanted to change it to


  
Hello
  


Is there a reason it could it not just be


  
  
Hello




There isn't really a significant difference between div and motor-scene to
non-supporting browsers.


-- 
Brian Kardell :: @briankardell

Re: Telecon / meeting on first week of April for Web Components

[Brian Kardell]

On Mar 21, 2016 3:17 PM, "Ryosuke Niwa"  wrote:
>
> For people participating from Tokyo and Europe, would you prefer having
it in early morning or late evening?
>
> Because Bay Area, Tokyo, and Europe are almost uniformly distributed
across the timezone, our time slots are limited:
>
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160405&p1=900&p2=248&p3=268
>
> Do people from Tokyo can participate in the meeting around midnight?
>
> If so, we can schedule it at UTC 3PM, which is 8AM in bay area, midnight
in Tokyo, and 5AM in Europe.
>
> Another option is at UTC 7AM, which is 11PM in bay area, 3PM in Tokyo,
and 8AM in Europe.
>
> - R. Niwa
>

I can afford to attend remotely! :)

Re: Art steps down - thank you for everything

[Brian Kardell]

On Jan 28, 2016 10:49 AM, "Chaals McCathie Nevile" 
wrote:
>
> Hi folks,
>
> as you may have noticed, Art has resigned as a co-chair of the Web
Platform group. He began chairing the Web Application Formats group about a
decade ago, became the leading co-chair when it merged with Web APIs to
become the Web Apps working group, and was instrumental in making the
transition from Web Apps to the Web Platform Group. (He also chaired
various other W3C groups in that time).
>
> I've been very privileged to work with Art on the webapps group for so
many years - as many of you know, without him it would have been a much
poorer group, and run much less smoothly. He did a great deal of work for
the group throughout his time as co-chair, efficiently, reliably, and
quietly.
>
> Now we are three co-chairs, we will work between us to fill Art's shoes.
It won't be easy.
>
> Thanks Art for everything you've done for the group for so long.
>
> Good luck, and I hope to see you around.
>
> Chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>

Thanks for all your efforts and work Art!  Also for coming to find me and
giving me a ride to TPAC when I got lost in Santa Clara.  Not all chairs
would do that :)

Re: Custom elements contentious bits

[Brian Kardell]

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren  wrote:

> On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola  wrote:
> > A bit ago Jan put together an initial draft of the "contentious bits"
> for custom elements, in preparation for our January F2F. Today I went
> through and expanded on the issues he put together, with the result at
> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits.
> It morphed into a kind of agenda for the meeting, containing "Previously
> contentious bits", "Contentious bits", "Other things to work out", and
> "Other issues worth mentioning".
> >
> > It would be lovely if other vendors could take a look, and fill in
> anything they think is missing, or correct any inaccuracies.
>
> So my impression is that Apple is still in favor of synchronous
> construction. Talking to developers from Ember.js they care about that
> too (to the extent they even think this problem is worthwhile
> solving). The "upgrade" problem is a more general problem we also have
> with service workers and such. There's some kind of boostrapping thing
> that might warrant a more general solution.
>
> Would be great to have some cards on the table.
>
> And with respect to that, Mozilla is interested in shipping Shadow
> DOM. We continue to have concerns with regards to lack of integration
> with the HTML Standard, but hope those will get resolved. Custom
> elements is less of a priority for us at this point, so we're not sure
> what to make of this meeting if things are still up in the air.
>
>
> --
> https://annevankesteren.nl/
>
>

I'd really like to understand where things really are with
async/sync/almost sync - does anyone have more notes or would they be
willing to provide more exlpanation?  I've read the linked contentious bit
and I'm still not sure that I understand.  I can say, for whatever it is
worth, that given some significant time now (we're a few years in) with web
component polyfills at this point I do see more clearly the desire for
sync.  It's unintuitive at some level in a world where we (including me)
tend to really want to make things async but if I am being completely
honest, I've found an increasing number of times where this is a actually
little nightmarish to deal with and I feel almost like perhaps this might
be something of a "least worst" choice.  Perhaps there's some really good
ideas that I just haven't thought of/stumbled across yet but I can tell you
that for sure a whole lot of frameworks and even apps have their own
lifecycles in which they reason about things and the async nature makes
this very hard in those cases.

Shadow DOM will definitely help address a whole lot of my cases because
it'll hide one end of things, but I can definitely see cases where even
that doesn't help if I need to actually coordinate.  I don't know if it is
really something to panic about but I feel like it's worth bringing up
while there are discussions going on.  The declarative nature and the
seeming agreement to adopt web-component _looking_ tags even in situations
where they are not exactly web components makes it easy enough to have
mutually agreeing "enough" implementations of things.  For example, I
currently have a few custom elements for which I have both a "native"
definition and an angular directive so that designers I know who write HTML
and CSS can learn a slightly improved vocabulary, say what they mean and
quickly get a page setup while app engineers can then simply make sure they
wire up the right implementation for the final product.  This wasn't my
first choice:  I tried going purely native but problems like the one
described above created way too much contention, more code, pitfalls and
performance issues.  In the end it was much simpler to have two for now and
reap a significant portion of the benefit if not the whole thing.

Anywho... I'm really curious to understand where this stands atm or where
various companies disagree if they do.


-- 
Brian Kardell :: @briankardell

Re: App-to-App interaction APIs - one more time, with feeling

[Brian Kardell]

 say that simple process is error prone. Maybe I am
> misunderstanding you?
>
>
>
> - Daniel
>
>
>
> From: Paul Libbrecht [mailto:p...@hoplahup.net]
> Sent: Sunday, October 18, 2015 9:38 AM
> To: Daniel Buchner 
> Cc: public-webapps@w3.org
> Subject: Re: App-to-App interaction APIs - one more time, with feeling
>
>
>
> Daniel,
>
> as far as I can read the post, copy-and-paste-interoperability would be a
> "sub-task" of this.
> It's not a very small task though.
> In my world, E.g., there was a person who inventend a "math" protocol
> handler. For him it meant that formulæ be read out loud (because his mission
> is making the web accessible to people with disabilities including eyes) but
> clearly there was no way to bring a different target.
>
> Somehow, I can't really be convinced by such a post except asking the user
> what is the sense of a given flavour or even protocol handler which, as we
> know, is kind of error-prone. Agree?
>
> paul
>
> PS: I'm still struggling for the geo URL scheme to be properly handled but
> it works for me in a very very tiny spectrum of apps (GMaps >
> Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This
> is certainly a good example of difficult sequence of choices.
>
>
>
>
> Paul Libbrecht
> 18 octobre 2015 18:38
> Daniel,
>
> as far as I can read the post, copy-and-paste-interoperability would be a
> "sub-task" of this.
> It's not a very small task though.
> In my world, E.g., there was a person who inventend a "math" protocol
> handler. For him it meant that formulæ be read out loud (because his mission
> is making the web accessible to people with disabilities including eyes) but
> clearly there was no way to bring a different target.
>
> Somehow, I can't really be convinced by such a post except asking the user
> what is the sense of a given flavour or even protocol handler which, as we
> know, is kind of error-prone. Agree?
>
> paul
>
> PS: I'm still struggling for the geo URL scheme to be properly handled but
> it works for me in a very very tiny spectrum of apps (GMaps >
> Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This
> is certainly a good example of difficult sequence of choices.
>
>
> Daniel Buchner
> 14 octobre 2015 18:33
>
> Hey WebAppers,
>
>
>
> Just ran into this dragon for the 1,326th time, so thought I would do a
> write-up to rekindle discussion on this important area of developer need the
> platform currently fails to address:
> http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/. We
> have existing APIs/specs that get relatively close, and my first instinct
> would be to leverage those and extend their capabilities to cover the
> broader family of use-cases highlighted in the post.
>
>
>
> I welcome your ideas, feedback, and commentary,
>
>
>
> - Daniel
>
>



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

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

working once there is a native .foo if that ever happens, but unless you go
and specifically opt in an update, make sure there isn't API breakage - you
won't get native benefits automatically, because we can't peer into a
crystal ball and know that will be the fact.



>
> > On Aug 7, 2015, at 7:07 AM, Brian Kardell  wrote:
> >
> > On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang  wrote:
> >> @William @Matthew
> >>
> >> Ah, thanks. Now I think prollyfill is prolly a good name. :)
> >>
> >> @Brian
> >>
> >> Actually, I had this pattern in mind:
> >>
> >> When no browsers ship the API:
> >>
> >> ```
> >> if (HTMLElement.prototype.foo) {
> >>  HTMLElement.prototype._foo = HTMLElement.prototype.foo;
> >> } else {
> >>  HTMLElement.prototype._foo = polyfill;
> >> };
> >> ```
> >
> > This assumes you'll match, which - again depending on how far you are
> > might be a big bet... Personally, I wouldn't use that myself if
> > writing something -- Seems a lot like  when people simply provided N
> > versions of the same prefixed properties instead of just one, it has
> > potential to go awry... No one can actually vary because they've done
> > the equivalent of shipping the unprefixed thing inadvertently
> > intending it to be an experiment, but it wasnt.
> >
> >>
> >> When at least two browsers ship this API:
> >>
> >> ```
> >> if (!HTMLElement.prototype.foo) {
> >> HTMLElement.prototype.foo = polyfill;
> >> }
> >> HTMLElement.prototype._foo = function() {
> >>  console.warn("deprecated");
> >>  return this.foo();
> >> };
> >> ```
> >
> > But it's not deprecated in browsers that don't support it, it's a
> > polyfill at that point and aside from the console.warn (which again,
> > in this case seems incorrect in the message at least) it should be
> > generally be identical to the oneliner I gave before - the prototype
> > for _foo is the polyfill version.
> >
> >
> >
> > --
> > Brian Kardell :: @briankardell :: hitchjs.com
>

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang  wrote:
> @William @Matthew
>
> Ah, thanks. Now I think prollyfill is prolly a good name. :)
>
> @Brian
>
> Actually, I had this pattern in mind:
>
> When no browsers ship the API:
>
> ```
> if (HTMLElement.prototype.foo) {
>   HTMLElement.prototype._foo = HTMLElement.prototype.foo;
> } else {
>   HTMLElement.prototype._foo = polyfill;
> };
> ```

This assumes you'll match, which - again depending on how far you are
might be a big bet... Personally, I wouldn't use that myself if
writing something -- Seems a lot like  when people simply provided N
versions of the same prefixed properties instead of just one, it has
potential to go awry... No one can actually vary because they've done
the equivalent of shipping the unprefixed thing inadvertently
intending it to be an experiment, but it wasnt.

>
> When at least two browsers ship this API:
>
> ```
> if (!HTMLElement.prototype.foo) {
>  HTMLElement.prototype.foo = polyfill;
> }
> HTMLElement.prototype._foo = function() {
>   console.warn("deprecated");
>   return this.foo();
> };
> ```

But it's not deprecated in browsers that don't support it, it's a
polyfill at that point and aside from the console.warn (which again,
in this case seems incorrect in the message at least) it should be
generally be identical to the oneliner I gave before - the prototype
for _foo is the polyfill version.



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

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Tue, Aug 4, 2015 at 8:22 PM, Glen Huang  wrote:

There's actually a lot of questions in here, so let me take them one
at a time...

> On second thought, what's the difference between prollyfills and libraries
A major difference is that it's hard to translate libraries into
standards regardless of the approach they use.  We just don't do it.
We have libraries like jQuery that are as successful as we can ever
reasonably expect anything to get - it's inarguable that jQuery is
used more than any single browser, for example - and yet we didn't
just standardize jQuery.   What's more, we wouldn't for lots of
technical and political reasons.  jQuery wasn't made with becoming a
standard in mind and it didn't propose things in same standards sense
before hand or early -- a lot of the approach/style matter too (see
below).  Aspects of it could have been - jQuery has individuals
representing in standards committees (me, for example) and prollyfills
give us a way to do this - ecma, for example, produces a lot of
prollyfills as they go and actually get use and feedback before it's
way too late.

> exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs 
> replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing 
> APIs doesn't seem to be that different from using custom APIs?

It could be, but the further you get from the actual way it will be
used, the more we will debate on what will happen if you change its
surface.  A prollyfill is as close as we can approximate to the real
proposal without shooting ourselves in the foot.  It lets developers
and standards people work together, answer questions about uptake and
confusion, identify use cases and edgecases, etc.

>You might say the prefixing approach resembles native APIs more closely, but 
>when changing your code to use native APIs, modifying one character or several 
>doesn't really make much difference (they are the same if you find & replace), 
>as long as you have to modify the code.

Definitely not as simple if you change the whole pattern - asking
someone to grep an entire codebase is a bigger ask than a nice simple
pattern that lets you just say something like:

// Hey, our prollyfill matches native, now it's a polyfill!
HTMLElement.prototype.foo = HTMLElement.prototype._foo;



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

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Mon, Aug 3, 2015 at 9:07 PM, Glen Huang  wrote:
> Brian,
>
> prollyfills seems pragmatic. But what about when the logic of an API changes, 
> but not the name? The node.replaceWith() API for example is about to be 
> revamped to cover some edge cases. If the prollyfills exposed 
> node._replaceWith(), what should it do when the new node.replaceWith() comes? 
> Expose node._replaceWith2()? This doesn't seem to scale.
>

Why would it need to?  Just like any library, you import a version and
deal with incompatibilities when you upgrade?


> But I do see the benefit of prefixing in prollyfills. node.replaceWith() used 
> to be node.replace(). If we exposed _replace() earlier, we can swap the 
> underlying function with node.replaceWith() when we release a new version, 
> and old code immediately benefit from the new API. But over time, prollyfills 
> are going to accumulate a lot obsolete APIs. Do you think we should use 
> semver to introduce breaking changes? Or these obsolete APIs should always be 
> there?
>

Yes, I think authors will opt in to an API and that API may contain
breaking changes or backcompat changes, I think that's up to people
implementing and maintaining to experiment with.  Too early to say
what will be more successful, but I don't forsee things growing
forever - at some point people remove polyfills too in practice... In
theory you could use something like FT-labs polyfill as a service to
make any browser 'normalized' but that gets really heavy if it isn't
targeted and goes back too far in practice.  No one is even writing
polyfills for IE6 anymore - most don't even go back to IE8.


> And if we are going this route, I think we need blessing from the WG. They 
> have to promise they will never design an API that starts with the prefix we 
> used.

We have that in web components already (no native element will be a
dasherized name - in most practical terms, attributes too), for all
things CSS (-vendor-foo just has no vendor and becomes --foo) and when
you're talking about DOM - yeah, we dont have one, but no DOM will
contain an leading underscore, I can just about promise that without
any agreements - but I agree it'd be great if we just had one.



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

Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang  wrote:
> I'm pretty obsessed with all kinds of web specs, and invest heavily in tools 
> based on future specs. I was discussing with Tab the other day about whether 
> he thinks using a css preprocessor that desugars future css is a good idea. 
> His answer was surprisingly (at least to me) negative, and recommended sass. 
> His arguments were that
>
> 1. the gramma is in flux and can change
> 2. css might never offer some constructs used in sass, at least with very low 
> priority.
>
> I think these are good points, and it reduced my enthusiasm for future spec 
> based css preprocessors. But this got me thinking about polyfills for future 
> web APIs. Are they equally not recommended? Likewise, the APIs might change, 
> and for DOM operations we should rely on React because the native DOM might 
> never offer such declarative APIs, at least with very low priority. Do 
> polyfills like WebReflection's DOM4 look promising? For new projects, should 
> I stick with polyfills that only offers compatibilities for older browser, 
> and for future spec features, only use libraries that offer similar features 
> but invent their own APIs, or should I track future specs and use these 
> "unstable" polyfills?
>
> I'm torn on this subject. Would like to be enlightened.
[snip]

TL;DR: Yes, I think they are good - really good actually, with some
best practices.

CSS is a slightly different beast at the moment because it is not
(yet) extensible, but let's pretend for a moment that it is so that a
uniform answer works ok...

This was why I and others advocated defining the idea of/using the
term "prollyfill" as opposed to a polyfill.  With a polyfill you are
filling in gaps and cracks in browser support for an established
standard, with a prollyfill you might be charting some new waters.  In
a sense, you're taking a guess.  If history is any indicator then the
chances that it will ultimately ship that way without change is very
small until it really ships in two interoperable browsers that way.
There's more to it than slight semantics too I think:  Polyfill was
originally defined as above and now for many developers the
expectation is that this is what it's doing.  In other words, it's
just providing a fill for something which will ultimately be native,
therefore won't change.  Except, as we are discussing, this might not
be so.  Personally, I think this matters in a big way because so much
depends on people understanding things:  If users had understood and
respected vendor-prefixed CSS for use as intended, for example, they
wouldn't have been much of a problem -- but they were.  Users didn't
understand that and things shipped natively, so vendors had to adjust
- things got messy.

Debates about this took up a lot of email space in early extensible
web cg lists - my own take remains unchanged, mileage may vary:

It is my opinion that when possible, we should 'prefix' prollyfilled
APIs - this could be something as simple as an underscore in DOM APIs
or a "--property" in CSS, etc.  Hopefully this makes it obvious that
it is not native and is subject to change, but that isn't the reason
to do it.  The reason to do it is the one above:  it *may* actually
change so you shouldn't mislead people to think otherwise - it
potentially affects a lot.  For example, if something gets very
popular masquerading as native but no one will actually implement
natively it without changes - they are stuck having to deal with
shitty compromises in standards to keep the web from breaking.  Also,
what happens when devs "sell" a standard with the promise that it's
going to be native and then we rip that rug out from underneath them.

For me then, following a nice pattern where authors opt in and provide
whether or not to prefix is ideal.  Since authors opt in, just like
they do with a library and it can work in all browsers, it can
version, and it's way better than vendor prefixes on native.  Yes,
your code won't "automatically" run faster if it is implemented
natively- but depending on how far along the track you are, it might
be very long odds that it will ship just like that.  If you get very
lucky, your last version of "prollyfill" becomes "polyfill" and if a
site wants to use the native, they can tweak a single arg and it's off
to the races.

Realistically, I think that prollyfills are probably the only way to
strike the right balance of incentives and disincentives that allow
the standards community to do good things, create a good feedback loop
that developers can actually be involved in and measure something
experimental before we ship it.

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

Re: Inheritance Model for Shadow DOM Revisited

[Brian Kardell]

On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa  wrote:
>
>> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren  wrote:
>>
>> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa  wrote:
>>> The problem with " as function" is that the superclass implicitly 
>>> selects nodes based on a CSS selector so unless the nodes a subclass wants 
>>> to insert matches exactly what the author of superclass considered, the 
>>> subclass won't be able to override it. e.g. if the superclass had an 
>>> insertion point with select="input.foo", then it's not possible for a 
>>> subclass to then override it with, for example, an input element wrapped in 
>>> a span.
>>
>> So what if we flipped this as well and came up with an imperative API
>> for " as a function". I.e. " as an actual function"?
>> Would that give us agreement?
>
> We object on the basis that " as a function" is fundamentally 
> backwards way of doing the inheritance.  If you have a MyMapView and define a 
> subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView 
> must be a MyMapView.  It doesn't make any sense for MyScrollableMapView, for 
> example, to be a ScrollView that then contains MyMapView.  That's has-a 
> relationship which is appropriate for composition.
>
> - R. Niwa
>


Is there really a hard need for inheritance over composition? Won't
composition ability + an imperative API that allows you to properly
delegate to the stuff you contain be just fine for a v1?



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

Re: Proposal for changes to manage Shadow DOM content distribution

[Brian Kardell]

On Apr 21, 2015 10:29 PM, "Ryosuke Niwa"  wrote:
>
>
>> On Apr 21, 2015, at 10:17 PM, Brian Kardell  wrote:
>>
>> On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  wrote:
>> >
>> > Hi all,
>> >
>> > Following WebApps discussion last year [1] and earlier this year [2]
about template transclusions and inheritance in shadow DOM, Jan Miksovsky
at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
a meeting where we came up with changes to the way shadow DOM distributes
nodes to better fit real world use cases.
>> >
>> > After studying various real world use of web component APIs as well as
exiting GUI frameworks, we noticed that selector based node distribution as
currently spec'ed doesn't address common use cases and the extra
flexibility CSS selectors offers isn't needed in practice.  Instead, we
propose named insertion "slots" that could be filled with the contents in
the original DOM as well as contents in subclasses.  Because the proposal
uses the same slot filling mechanism for content distributions
and inheritance transclusions, it eliminates the need for multiple shadow
roots.
>> >
>> > Please take a look at our proposal at
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
>> >
>> > [1]
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
>> > [2]
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
>> >
>>
>> I just wanted to note that a month or two I tried to assume nothing and
come up with a bare essentials concept which involved named slots.  Is
there a proposed a way to project from an attribute value into content or
from attribute to attribute..?
>>
>> In other words, if I had . Can I map blah into a
slot or identify an attribute value in my template *as* a slot?
>
> Not at the moment but I could imagine that such a feature could be easily
added. e.g.
>
> 
>
> 
> 
>   
> 
>
> - R. Niwa
>

For the record, I'd love to see that discussed as part of a real proposal
because I think it's pretty useful - you can see lots of things essentially
trying to do custom elements in the wild with a similar need and it
honestly seems easier than element based slots technically speaking so it
would be a shame to lack it.

Re: Proposal for changes to manage Shadow DOM content distribution

[Brian Kardell]

On Apr 21, 2015 8:22 PM, "Ryosuke Niwa"  wrote:
>
> Hi all,
>
> Following WebApps discussion last year [1] and earlier this year [2]
about template transclusions and inheritance in shadow DOM, Jan Miksovsky
at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had
a meeting where we came up with changes to the way shadow DOM distributes
nodes to better fit real world use cases.
>
> After studying various real world use of web component APIs as well as
exiting GUI frameworks, we noticed that selector based node distribution as
currently spec'ed doesn't address common use cases and the extra
flexibility CSS selectors offers isn't needed in practice.  Instead, we
propose named insertion "slots" that could be filled with the contents in
the original DOM as well as contents in subclasses.  Because the proposal
uses the same slot filling mechanism for content distributions
and inheritance transclusions, it eliminates the need for multiple shadow
roots.
>
> Please take a look at our proposal at
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
>
> [1]
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
> [2]
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
>

I just wanted to note that a month or two I tried to assume nothing and
come up with a bare essentials concept which involved named slots.  Is
there a proposed a way to project from an attribute value into content or
from attribute to attribute..?

In other words, if I had . Can I map blah into a slot
or identify an attribute value in my template *as* a slot?

Re: Minimum viable custom elements

[Brian Kardell]

On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:

> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>
>>
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>> wrote:
>>
>>> Yeah, I had noted in that post that wrapping a native element with a
>>> custom element was an option - only drawback is that the markup isn't as
>>> terse (which is generally advertised as one of the selling points of Custom
>>> Elements). But that doesn't seem like a deal breaker to me, if subclassing
>>> needs to be postponed.
>>>
>>> Chris
>>>
>>>
>> As I pointed out ealier:
>>
>> 
>>
>> 
>>
>> seems like barely a ternseness savings worth discussing.
>>
>>
>> Indeed.  Also, authors are used to the idea of including a fallback
>> content inside an element after canvas and object elements and this fits
>> well with their mental model.
>>
>
> I'm just trying to get my head around this pattern. In this example, does
> the web page author or the custom element developer embed the input? And
> who is responsible for syncing the relevant attributes across? In reality,
> isn't this going to look more like
>
> 
> 
> 
>
> or as a slightly contrived example,
>
> 
> 
> 
>
> Or does the custom element get its state from the embedded element?
>

the custom element uses its contents as input and, in the simplest sense,
just moves it or maps it during creation... In a more complicated world
with something more like shadow dom (a separate topic) it might be
'projected'

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

Re: Minimum viable custom elements

[Brian Kardell]

On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman  wrote:

> Yeah, I had noted in that post that wrapping a native element with a
> custom element was an option - only drawback is that the markup isn't as
> terse (which is generally advertised as one of the selling points of Custom
> Elements). But that doesn't seem like a deal breaker to me, if subclassing
> needs to be postponed.
>
> Chris
>
>
As I pointed out ealier:





seems like barely a ternseness savings worth discussing.



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay  wrote:

> On 02/03/2015 04:22 PM, Brian Kardell wrote:
>
>>
>>
>> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay > o...@pettay.fi>> 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/
>> <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.
>
>
[snip]

> If ShadowRoot had something like attribute DOMString name?; which defaults
>> to null and null means deep(name) or deep(*) wouldn't be able
>>
> to find the mount, that would let the component itself to say whether it
> can deal with outside world poking it CSS.


That actually doesn't sound crazy to me.  I mean, it actually fits
pretty nicely into the conceptual model I think and it would add a whole
additional layer of possible protection which is explainable in sort of
"todays terms" with minimal new 'stuff'... the combinator is new anyway and
you're dealing with mount in what seems like a good way there.  I think I
like it.


[snip]

> [Perhaps a bit off topic to the style isolation]
> In other words, I'm not very happy to add super complicated Shadow DOM to
> the platform if it doesn't really provide anything new which
> couldn't be implemented easily with script libraries and a bit stricter
> coding styles and conventions.


I'd suggest that you're radically over-stating - you really can't "easily
solve this problem", even with much stricter coding style, as I explained
in that post.  This is a problem and even without named mount protection
above, this would be a giant leap forward because the -default- thing is to
not match.  Doing 'right' by default is a giant win.  That said, as I say
above, I kinda like the named mount idea...


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

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

Re: Minimum viable custom elements

[Brian Kardell]

On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson  wrote:
[snip]


> "a really first-class fallback option if you don't support JS" is
> vital for the quarter of a billion people who use Opera Mini and the
> 100 million people who use the Nokia proxy browser. Fallback rather
> than non-functional pages is vital for the people who don't use latest
> greatest Chromium or Gecko browsers.
>
> b
>

But in the context of custom elements (not shadow dom) these should be able
to do 'createdCallback' etc on the server... I can't really see any reason
why they couldn't/wouldn't.

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

Re: Minimum viable custom elements

[Brian Kardell]

On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn 
wrote:

>
>
> On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell  wrote:
>
>>
>>
>> On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson  wrote:
>>
>>> On 29 January 2015 at 14:54, Steve Faulkner 
>>> wrote:
>>> > I think being able to extend existing elements has potential value to
>>> > developers far beyond accessibility (it just so happens that
>>> accessibility
>>> > is helped a lot by re-use of existing HTML features.)
>>>
>>> I agree with everything Steve has said about accessibility. Extending
>>> existing elements also gives us progressive enhancement potential.
>>>
>>> Try https://rawgit.com/alice/web-components-demos/master/index.html in
>>> Safari or IE. The second column isn't functional because it's using
>>> brand new custom elements. The first column loses the web componenty
>>> sparkles but remains functional because it extends existing HTML
>>> elements.
>>>
>>> There's a similar story with Opera Mini, which is used by at least
>>> 250m people (and another potential 100m transitioning on Microsoft
>>> feature phones) because of its proxy architecture.
>>>
>>> Like Steve, I've no particularly affection (or enmity) towards the
>>>  syntax. But I'd like to know,
>>> if it's dropped, how progressive enhancement can be achieved so we
>>> don't lock out users of browsers that don't have web components
>>> capabilities, JavaScript disabled or proxy browsers. If there is a
>>> concrete plan, please point me to it. If there isn't, it's
>>> irresponsible to drop a method that we can see working in the example
>>> above with nothing else to replace it.
>>>
>>> I also have a niggling worry that this may affect the uptake of web
>>> components. When I led a dev team for a large UK legal site, there's
>>> absolutely no way we could have used a technology that was
>>> non-functional in older/proxy browsers.
>>>
>>> bruce
>>>
>>>
>> Humor me for a moment while I recap some historical arguments/play
>> devil's advocate here.
>>
>> One conceptual problem I've always had with the is="" form is that it
>> adds some amount of ambiguity for authors and makes it plausible to author
>> non-sense.  It's similar to the problem of aria being "bolt on" with mix
>> and match attributes.  With the imperative form of extending you wind up
>> with a tag name that definitely is defined as subclassing something
>> " 'inherits' from HTMLButtonElement and I'll explain how it's
>> different".  With the declarative attribute form you basically have to
>> manage 3 things: ANY tag, the base class and the final definition.  This
>> means it's possible to do things like  which likely
>> won't work.  Further, you can then proceed to define something which is
>> clearly none-of-the-above.
>>
>
> The is@ only works on the element you defined it to apply to, so  is="button"> does nothing unless the element "button" was registered as a
> type extension to "iframe". I don't see that as any more error prone than
> writing  instead of .
>
> In other words, if there are 350 elements in HTML - in 349 you could say
is="button" and it would do nothing.  This isn't possible with the pure tag
form, it either is or isn't the tag.  This is all I described - ambiguity
for authors and ability to author nonsense.  Maybe it is 'benign' nonsense
but it's nonsense and potentially frustrating in a way that misspelling a
tag isn't IMO.


> Also fwiw most "share" buttons on the web are actually iframes, so  is="facebook-button"> makes total sense.
>

youre somewhat locked into thinking that because it's how we've dealt with
things, don't you think?  I mean  might conceptually
work too, but we know that they're iframes for SOP/isolation reasons.  That
said, what exactly would you add to your custom element facebook-button
that adds value then?  ... Like... what could you legitimately do with that
that you couldn't do with ?  Would it
actually submit a form in *your* page, would your focus act the same, etc?
I'm asking for real because I think the use-cases are on the small end of
limited

I'm not saying it's better or worse, I'm actually trying to take the devils
advocate position here because there might be something beneath it worth
thinking about...  It does seem that composition actually seems to let you
express something equally good without ambiguity more easily except insofar
as giving you a really first-class fallback option if you don't support JS,
but... I'm having a really hard time imagining more than 3-4 cases  where
that's really a useful thing.



> - E
>



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

Re: Minimum viable custom elements

[Brian Kardell]

On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson  wrote:

> On 29 January 2015 at 14:54, Steve Faulkner 
> wrote:
> > I think being able to extend existing elements has potential value to
> > developers far beyond accessibility (it just so happens that
> accessibility
> > is helped a lot by re-use of existing HTML features.)
>
> I agree with everything Steve has said about accessibility. Extending
> existing elements also gives us progressive enhancement potential.
>
> Try https://rawgit.com/alice/web-components-demos/master/index.html in
> Safari or IE. The second column isn't functional because it's using
> brand new custom elements. The first column loses the web componenty
> sparkles but remains functional because it extends existing HTML
> elements.
>
> There's a similar story with Opera Mini, which is used by at least
> 250m people (and another potential 100m transitioning on Microsoft
> feature phones) because of its proxy architecture.
>
> Like Steve, I've no particularly affection (or enmity) towards the
>  syntax. But I'd like to know,
> if it's dropped, how progressive enhancement can be achieved so we
> don't lock out users of browsers that don't have web components
> capabilities, JavaScript disabled or proxy browsers. If there is a
> concrete plan, please point me to it. If there isn't, it's
> irresponsible to drop a method that we can see working in the example
> above with nothing else to replace it.
>
> I also have a niggling worry that this may affect the uptake of web
> components. When I led a dev team for a large UK legal site, there's
> absolutely no way we could have used a technology that was
> non-functional in older/proxy browsers.
>
> bruce
>
>
Humor me for a moment while I recap some historical arguments/play devil's
advocate here.

One conceptual problem I've always had with the is="" form is that it adds
some amount of ambiguity for authors and makes it plausible to author
non-sense.  It's similar to the problem of aria being "bolt on" with mix
and match attributes.  With the imperative form of extending you wind up
with a tag name that definitely is defined as subclassing something
" 'inherits' from HTMLButtonElement and I'll explain how it's
different".  With the declarative attribute form you basically have to
manage 3 things: ANY tag, the base class and the final definition.  This
means it's possible to do things like  which likely
won't work.  Further, you can then proceed to define something which is
clearly none-of-the-above.

With the imperative form you can pretty clearly grok it and avoid a class
of errors which you couldn't otherwise.  Still, getting this right in
implementation is actually really hard and, as such, will require a lot of
debate - similarly, because it's kind of 'mix in' oriented (that is, what
you have is 'features of a button which are, unfortunately potentially
based on complicated DOM which isn't a button) it's still further
complicated to figure out the right thing to base off of... Only in a
vanishingly small number of cases like the oft repeated 'custom button' is
this not the case, but even there you can imagine that if you really need
to extend a button, you're asking for 'more than a button' and it might get
swampy.

Let's imagine you have none of that though and you want a custom button
which involves some dom that isn't just 'button'.  How would you write it?
Most likely through composition - that is, it would likely -contain- a
button.  This is considerably simpler and in many ways more intuitive and
it has approximately the same accessibility benefit as far as I can tell.
It's probably not 'the best we can do' but it might not be a bad start if
we had to start there.

With regard to 'what about if you have javascript turned off' - again,
there are a class of problems where there are easy to employ patterns and a
class of problems where that is just not the case and can't be.  I think we
have to be very cautious about that.  If you have a custom element with a
src="" attribute, for example, the best you are going to be able to do is
graceful degradation with the stuff kinda already built into HTML - things
like noscript and unknown element stuff.  As for pre-renderers, what I've
described isn't so complicated that I think pre-renderers can't get it
right, but maybe I am misunderstanding.






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

Re: Minimum viable custom elements

[Brian Kardell]

On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola  wrote:

> Steve's concerns are best illustrated with a more complicated element like
> . He did a great pull request to the custom elements spec that
> contrasts all the work you have to do with  vs.  is="tequila-button">:
>
> https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs.
> https://w3c.github.io/webcomponents/spec/custom/#type-extension-example
>
> The summary is that you *can* duplicate *some* of the semantics and
> accessibility properties of a built-in element when doing custom tags, but
> it's quite arduous. (And, it has minor undesirable side effects, such as
> new DOM attributes which can be overwritten, whereas native role semantics
> are baked in.)
>
> Additionally, in some cases you *can't* duplicate the semantics and
> accessibility:
>
>
> https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md#incomplete-mitigation-strategies
>
> An easy example is that you can never get a screen reader to announce
>  as a paragraph, while it will happily do so for  is="custom-p">. This is because there is no ARIA role for paragraphs that
> you could set in the createdCallback of your CustomP.
>
> However, this second point is IMO just a gap in the capabilities of ARIA
> that should be addressed. If we could assume it will be addressed on the
> same timeline as custom elements being implemented (seems ... not
> impossible), that still leaves the concern about having to duplicate all
> the functionality of a button, e.g. keyboard support, focus support,
> reaction to the presence/absence of the disabled attribute, etc.
>
> -Original Message-
> From: Edward O'Connor [mailto:eocon...@apple.com]
> Sent: Thursday, January 15, 2015 18:33
> To: WebApps WG
> Subject: Re: Minimum viable custom elements
>
> Hi all,
>
> Steve wrote:
>
> >> [I]t also does not address subclassing normal elements. Again, while
> >> that seems desirable
> >
> > Given that subclassing normal elements is the easiest and most robust
> > method (for developers) of implementing semantics[1] and interaction
> > support necessary for accessibility I would suggest it is undesirable
> > to punt on it.
>
> Apologies in advance, Steve, if I'm missing something obvious. I probably
> am.
>
> I've been writing an article about turtles and I've gotten to the point
> that six levels of headings aren't enough. I want to use a seventh-level
> heading element in this article, but HTML only has h1–6. Currently, without
> custom elements, I can do this:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> Suppose instead that TedHaitchSeven is a subclass of HTMLElement and I've
> registered it as . In its constructor or createdCallback or
> whatever, I add appropriate role and aria-level attributes. Now I can write
> this:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> This is just as accessible as the  was, but is considerably more
> straightforward to use. So yay custom elements!
>
> If I wanted to use is="" to do this, I guess I could write:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> How is this easier? How is this more robust?
>
> I think maybe you could say this is more robust (if not easier) because,
> in a browser with JavaScript disabled, AT would see an .  is at
> least a heading, if not one of the right level. But in such a browser the
>  example above is even better, because AT would see both that the
> element is a heading and it would also see the correct level.
>
> OK, so let's work around the wrong-heading-level-when-JS-is-disabled
> problem by explicitly overriding 's implicit heading level:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> I guess this is OK, but seeing aria-level=7 on and  rubs me the wrong
> way even if it's not technically wrong, and I don't see how this is easier
> or more robust than the other options.
>
>
> Thanks,
> Ted
>
>

I think you really need look no further than HTML as Custom Elements work
to see how difficult it would be to get accessibility right even if we had
good APIs, which, as Domenic pointed out, we really don't.

Anyway, it seems like one of the biggest criticisms we have seen of custom
elements anyone has made has to do with accessibility... It definitely
doesn't seem desirable to make it *harder* to get that right if we can
avoid it, because this could definitely play into the success or failure
story writ large.



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

Re: Minimum viable custom elements

[Brian Kardell]

Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Jan 13, 2015 at 8:09 PM, Ryosuke Niwa  wrote:

>
> On Jan 13, 2015, at 3:46 PM, Brian Kardell  wrote:
>
>
>
> On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa  wrote:
>
> To separate presentational information (CSS) from the semantics (HTML).
>> Defining both style isolation boundaries and the associated CSS rules in an
>> external CSS file will allow authors to change both of them without having
>> to modify every HTML documents that includes the CSS file.  Of course, this
>> is a non-starter for Web apps that require a lot of scripting, but style
>> isolation is a very useful feature for a lot of static pages as well.
>>
>> - R. Niwa
>>
>>
> Ryosuke,
>
> Should you also be able to do this from JavaScript/DOM in your opinion?
> Like, forget shadow dom as it is today in chrome or proposed -- should you
> be able to do something like
>
> ```
> element.isolateTree = true;
> ```
>
> and achieve a similar effect?  If not, why specifically?
>
>
> Or element.setAttribute('isolatetree', true);  I can't think of a reason
> not to do this.
>
> - R. Niwa
>
>
So if that is a given, why can we not start there and explain how it would
work and use it to fashion increasingly high abstractions - hopefully with
the ability to do some experimentation outside of native implementations?


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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa  wrote:

To separate presentational information (CSS) from the semantics (HTML).
> Defining both style isolation boundaries and the associated CSS rules in an
> external CSS file will allow authors to change both of them without having
> to modify every HTML documents that includes the CSS file.  Of course, this
> is a non-starter for Web apps that require a lot of scripting, but style
> isolation is a very useful feature for a lot of static pages as well.
>
> - R. Niwa
>
>
Ryosuke,

Should you also be able to do this from JavaScript/DOM in your opinion?
Like, forget shadow dom as it is today in chrome or proposed -- should you
be able to do something like

```
element.isolateTree = true;
```

and achieve a similar effect?  If not, why specifically?




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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 7:45 PM, Ryosuke Niwa  wrote:

>
> I understand your use case but please also understand that some authors
> don't want to write a few dozen lines of JavaScript to create a shadow DOM,
> and hundreds of lines of code or load a framework to decoratively isolate
> CSS rules in their pages.
>
> As far as I can tell, I am not talking about shadow dom or specifically
what authors would have to write... If I did, I didn't intend to do so.  I
am talking about how it is explained and where.  It could literally be as
simple as a single line of JavaScript for purposes of what I am discussing
- As anne mentioned earlier, it could just be a property of an element
potentially... Maybe you could even do with markup attribute.  I thought
that what we were discussing was how to isolate the simpler/potentially
less controversial bits of this.  Conceptually then, my point then is about
when you isolate to prevent accidental style leakage, it seems you nearly
always want to prevent qsa and traversal kinds of leakage too, and that it
wouldn't hurt you in some very rare case where you didn't explicitly *want*
it, as long as you can explicitly traverse the boundary with a combinator.



> Quick note based on some of your other responses - I actually didn't see
> any proposal in the suggestions about TreeScope or a non-parent/child link
> connector or something that talked about insertion points... I think that
> is a secondary question, as is event retargeting?  My comments are
> literally limited to the bare minimum stuff above without discussion of
> those.
>
>
> What questions do you have with regards with insertion points and event
> retargeting?  Are you asking whether they should happen as a side effect of
> having a style isolation?
>

I'm saying that you can talk about isolation without insertion points or
event retargeting, which is what I got out of the thread topic.  Maybe I'm
wrong?


> I would just say that we feel event retargeting should be treated as a
> separate concern from style isolation.  I'm denying that a style isolation
> with event retargeting is a valid use case but there are use cases in which
> style isolation without event retargeting is desirable or retargeting needs
> to be implemented by frameworks.
>

Now I'm quite confused.  IIRC you are the one that brought up insertion
points earlier - was someone else talking about them?  In any case, I agree
with you, it's possible to have this conversation without those two as a
start and I'd suggest we do that.



>
> - R. Niwa
>
>


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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 7:23 PM, Ryosuke Niwa  wrote:

>
> On Jan 12, 2015, at 4:16 PM, Brian Kardell  wrote:
>
>
>> Sure, here are some use cases I can think off the top of my head:
>>
>>1. Styling a navigation bar which is implemented as a list of
>>hyperlinks
>>2. Styling an article in a blog
>>3. Styling the comment section in a blog article
>>4. Styling a code snippet in a blog article
>>
>> None of these scenarios require authors to write scripts.
>>
>> - R. Niwa
>>
>>
> I'm sorry, this might be dense but as use cases go those seem
> incomplete I believe you intend to illustrate something here, but I'm
> not getting it... Is the idea that the nav bar wants to deliver "this is
> how I am styled" without interference from the page, potentially through
> some assembly on the server or preprocess or something?   Or it is just
> like "this is actually really hard to manage" with CSS and here's
> potentially a way to make it 'scope' easier?
>
>
> It's both that the navigation bar wants to have its own set of CSS rules
> and doesn't want to get affected by other CSS rules; and it's hard to
> manage a large number of CSS rules manually without an encapsulation
> mechanism like a style isolation boundary [1].
>
> [1] http://stackoverflow.com/questions/2253110/managing-css-explosion
>
> - R. Niwa
>
>
Yeah, ok, that's what I thought you meant.  Professionally, I come up with
this case all the time and the number of cases where I want JavaScript ops
to inadvertently poke into me is 0.  Let's use your menu case, lets say
that I have a class="title" on some menu elements and use id="main" -
because, hey, that's one reason we like style isolation, we don't need to
invent complex strategies.  Fairly high odds that someone else in the page
will qsa those and do something bad to me inadvertently.  Having those
respect the same boundary for the same seems very, very natural to me.

Quick note based on some of your other responses - I actually didn't see
any proposal in the suggestions about TreeScope or a non-parent/child link
connector or something that talked about insertion points... I think that
is a secondary question, as is event retargeting?  My comments are
literally limited to the bare minimum stuff above without discussion of
those.




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

Re: Shadow tree style isolation primitive

[Brian Kardell]

>
>
> Sure, here are some use cases I can think off the top of my head:
>
>1. Styling a navigation bar which is implemented as a list of
>hyperlinks
>2. Styling an article in a blog
>3. Styling the comment section in a blog article
>4. Styling a code snippet in a blog article
>
> None of these scenarios require authors to write scripts.
>
> - R. Niwa
>
>
I'm sorry, this might be dense but as use cases go those seem
incomplete I believe you intend to illustrate something here, but I'm
not getting it... Is the idea that the nav bar wants to deliver "this is
how I am styled" without interference from the page, potentially through
some assembly on the server or preprocess or something?   Or it is just
like "this is actually really hard to manage" with CSS and here's
potentially a way to make it 'scope' easier?


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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 5:18 PM, Ryosuke Niwa  wrote:

> [snip]
> I agree that having both style isolation and subtree isolation is
> desirable in some use cases such as Web app widgets.  However, there are
> other use cases for which style isolation without subtree isolation is
> desirable in non-App Web documents.
>
> - R. Niwa
>
> Can you share such a case? If you're worried about CSS selectors 'bleeding
through' how do functional selectors not have precisely the same concerns?
I'm not saying it doesn't exist, I'm saying that I am having trouble
envisioning it and would like some more information.  It does seem to me
that both sorts of isolation naturally 'fall out' of simply having a
connector of trees that isn't using parent/child pointers and that most
things would "just work" and be easy to explain (as a thing on its own and
to use to build up higher features) which is an aspect I am having trouble
seeing in nearly all other proposals.  Once again, I'm not saying it's not
there, I'm just asking for someone to explain/show me.



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 4:57 PM, Ryosuke Niwa  wrote:

>
> > On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote:
> >
> > 09.01.2015, 16:42, "Anne van Kesteren" :
> >> I'm wondering if it's feasible to provide developers with the
> >> primitive that the combination of Shadow DOM and CSS Scoping provides.
> >> Namely a way to isolate a subtree from selector matching (of document
> >> stylesheets, not necessarily user and user agent stylesheets) and
> >> requiring a special selector, such as >>>, to pierce through the
> >> boundary.
> >
> > Sounds like a reasonable, and perhaps feasible thing to do, but the
> obvious question is "why?"
> >
> > The use cases I can think of are to provide the sort of thing we do with
> BEM today. Is the effort worth it, or are there other things I didn't think
> of (quite likely, given I spent multiple seconds on the question)?
>
> The benefit of this approach is that all the styling information will be
> in one place.  CSS cascading rules is already complicated, and having to
> consult the markup to know where the selector boundary is will be yet
> another cognitive stress.
>
> - R. Niwa
>
>
If it it necessary to reflect similar at the imperative end of things with
qsa/find/closest (at minimum) - and I think it is the least surprising
thing to do - then you've merely moved where the cognitive stress is, and
in a really new way... Suddenly your CSS is affecting your understanding of
the actual tree!  That seems bad.



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 11:51 AM, Anne van Kesteren 
wrote:

> On Mon, Jan 12, 2015 at 5:47 PM, Brian Kardell  wrote:
> > Controlling it through CSS definitely seems to be very high-level.  To
> me at
> > least it feels like it requires a lot more answering of "how" since it
> deals
> > with identifying elements by way of rules/selection in order to
> > differentially identify other elements by way of rules/selection.  At the
> > end of the day you have to identify particular elements as different
> somehow
> > and explain how that would work.  It seems better to start there at a
> > reasonably low level and just keep in mind that it might be a future aim
> to
> > move control of this sort of thing fully to CSS.
>
> I'm not sure I agree. Unless you make all of CSS imperative it seems
> really hard to judge what belongs where.
>

It's important that at least qsa/find/closest style things defined in
Selectors match the same in script as in CSS matching.  Whatever solution
likely needs to include this consideration.

I've heard some worries about async/sync requirements regarding rendering
here but I'd say it's further than that if it's rule based too from my
perspective - this seems like something we're going to have to deal with
anyway in a larger sense of extensibility.  I wouldn't (personally) let
that dictate that we can't do this in script - there are lots of places
where that seems practical/controllable enough even now and we could make
globally better with some effort.

Basing this off something in CSS matching, as opposed to DOM means that new
roots can come into play (or leave) in a document-wide sense based on the
addition or removal or rules.  This seems confusing and problematic to me
and the combination of these was relevant to my comment about what's
matching what.  It seems to me that identifying a shadow root is concrete
to an instance and once it's there, it's there.  You can consciously choose
to combinator select through it or not, but it's there unless the physical
DOM changes.



> --
> https://annevankesteren.nl/
>



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Mon, Jan 12, 2015 at 7:04 AM, Anne van Kesteren  wrote:

> On Fri, Jan 9, 2015 at 10:11 PM, Tab Atkins Jr. 
> wrote:
> > tl;dr: Cramming a subtree into a TreeScope container and then hanging
> > that off the DOM would do the job "for free" (because it bakes all
> > that functionality in).
>
> Sure, or we could expose a property that when set isolates a tree.
> Both a lot simpler than requiring ShadowRoot. However, it seems to me
> that ideally you can control all of this through CSS. The ability to
> isolate parts of a tree and have them managed by some other stylesheet
> or selector mechanism.
>

Controlling it through CSS definitely seems to be very high-level.  To me
at least it feels like it requires a lot more answering of "how" since it
deals with identifying elements by way of rules/selection in order to
differentially identify other elements by way of rules/selection.  At the
end of the day you have to identify particular elements as different
somehow and explain how that would work.  It seems better to start there at
a reasonably low level and just keep in mind that it might be a future aim
to move control of this sort of thing fully to CSS.  Since CSS matching
kind of conceptually happens on 'not exactly the DOM tree' (pseudo
elements, for example) it seems kind of similar to me and it might be worth
figuring that out before attempting another high-level feature which could
make answering 'what's the path up' all that much harder.

















> --
> https://annevankesteren.nl/
>



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Fri, Jan 9, 2015 at 10:49 AM, Anne van Kesteren  wrote:

>
> I wasn't suggesting anything since I'm not sure what the best way
> would be. It has to be some flag that eventually ends up on an element
> so when you do selector matching you know what subtrees to ignore. If
> you set that flag through a CSS property you'd get circular
> dependencies, but perhaps that can be avoided somehow. Setting it
> through an element or attribute would violate separation of style and
> markup.
>
> Yeah, these are the reasons I ask - shadowRoot IMO kind of solves these
parts of the problem in really the only sensible way I can imagine, but I
think what you're saying is "it's too much" - and - is there a lesser
thing, something maybe underneath that proposal which just offers this
part.  That's why I say, kind of a "fragment root" of which maybe if we get
to shadow dom it could be a special type of?  I guess you're not proposing
that but I am saying "what about a proposal like that" would it answer your
concerns?


>
> --
> https://annevankesteren.nl/
>



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

Re: Shadow tree style isolation primitive

[Brian Kardell]

On Jan 9, 2015 8:43 AM, "Anne van Kesteren"  wrote:
>
> I'm wondering if it's feasible to provide developers with the
> primitive that the combination of Shadow DOM and CSS Scoping provides.
> Namely a way to isolate a subtree from selector matching (of document
> stylesheets, not necessarily user and user agent stylesheets) and
> requiring a special selector, such as >>>, to pierce through the
> boundary.
>
> This is a bit different from the `all` property as that just changes
> the values of all properties, it does not make a selector such as
> "div" no longer match.
>
> So to be clear, the idea is that if you have a tree such as
>
>   
> Example
>  ... 
>   
>
> Then a simple div selector would not match the innermost div if we
> isolated the section. Instead you would have to use section >>> div or
> some such. Or perhaps associate a set of selectors and style
> declarations with that subtree in some manner.
>
>
> --
> https://annevankesteren.nl/
>

For clarity, are you suggesting you'd control the matching boundary via CSS
somehow or you'd need an indicator in the tree?  A new element/attribute or
something like a "fragment root" (sort of a shadowroot-lite)?

Re: [shadow dom] relitigation

[Brian Kardell]

On Wed, Dec 17, 2014 at 4:59 PM, Ryosuke Niwa  wrote:
>
>
> On Dec 17, 2014, at 3:18 PM, Brian Kardell  wrote:
>
> On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa  wrote:
>>
>> Hi Brian,
>>
>> The WebKit team has given a lot of feedback over the years on the Shadow
>> DOM spec.  We wouldn't have done that if we didn't care about it. :)  We're
>> excited to hear that Mozilla is planning to give more feedback on Custom
>> Elements and Shadow DOM because we feel that much of their feedback
>> resonates with us.
>>
>> Having said that, our feedback has largely been dismissed or has not been
>> adequately addressed.  I'm sure you can imagine that this does not
>> encourage us to invest much more time or effort into providing additional
>> feedback.
>>
>
> I can definitely appreciate that when you sink time into discussion and
> things don't appear to go that way it seems frustrating and doesn't promote
> good feelings about investing further.  At the same time, I'm sure you can
> appreciate that this leaves things in a frustrating/confusing spot for so
> many developers and their orgs around the world because of where this
> particular piece of the puzzle lies.  I'm glad to hear that Mozilla's
> position/feedback resonates but I'm still unclear.
>
>
> I sympathize with the sentiment.  However, regardless of which browsers
> implement Shadow DOM and Custom Elements today, Web developers won't be
> able to use them without fallbacks since many users would be using older
> Web browsers that don't support these features.
>

Hopefully you don't mean this to the extent it sounds.  A whole lot of the
Web doesn't follow this model and there is a point past which this approach
increases complexity to the point where it is unmanageable. If tomorrow
everyone shipped these APIs interoperably (I won't hold my breath, I'm just
making a point) then within a few months this would be the common target
for vast swaths of the Web and private enterprise, try surfing the Web with
IE6 and if you're very lucky most of it will simply be prompting you to
upgrade your browser.  If your point is simply that until this is the case,
you'll have to ship polyfills - that's my whole point.  It's impossible to
polyfill that which is not yet agreed to, and where this fits in the puzzle
it's hard to even get it close.  If we were to say 'it's going to work just
like it does in chrome when we get around to it, and we will' (note: not
advocating this, just making a point) then there would be good reason to
consider using the polyfill.  Currently, it looks more like a prollyfill
and you might be stuck with it forever.  If we were stuck with
.registerElement forever, or even HTML Imports, it's probably not the end
of the world.  If they work for you today, they should work even better for
you tomorrow as the trend of perf is always faster.  But shadow dom is big
and complex and a different kind of bet.  We might be willing to use it for
development, even in production for smaller projects if it looks pretty
probable that we'll remove it and gain perf and drop the scary code.  It's
a different proposition if you can't.



>
> I have followed all of these discussions pretty closely and even today
> after some searching I am not sure about which feedback regarding Shadow
> DOM specifically you feel still requires addressing?  Discussion about type
> 1, 2 boundary seems to have died off - was there some other?
>
>
> We've argued not to expose the shadow root of a host by default many
> times.  In fact, we got an agreement over a year ago to add a private mode
> (type II encapsulation) to the Shadow DOM.  However, the corresponding bug
> [1], which was filed in November 2012, hasn't been resolved yet.
>

Yes, I commented on it then too... thanks for the other links below too, I
couldn't find them but I recall now.  To be honest, I didn't get the
relationship with the transclusion thing[2] even then - seemed to mix
concerns to me.  Did anyone else bite on it?  I don't see anything
positive, but it's possible I missed it given that I was away during this
time.  I'm very curious on where that landed though in terms of who else
thought this was a problem/needed addressing like this.  #3 seems mostly
relevant to things beyond shadow root, like how it fits with imports.  Is
there some way to limit the scope and solve Shadow DOM L1 without imports
and saying only in the same origin or something?

What about this? Is it plausible to fork the draft and the prollyfills in
polymer and work out a counter-proposal?  While some might be unhappy that
Chrome released something unprefixed/not flagged on this front, you 

Re: [shadow dom] relitigation

[Brian Kardell]

On Wed, Dec 17, 2014 at 3:24 PM, Ryosuke Niwa  wrote:
>
> Hi Brian,
>
> The WebKit team has given a lot of feedback over the years on the Shadow
> DOM spec.  We wouldn't have done that if we didn't care about it. :)  We're
> excited to hear that Mozilla is planning to give more feedback on Custom
> Elements and Shadow DOM because we feel that much of their feedback
> resonates with us.
>
> Having said that, our feedback has largely been dismissed or has not been
> adequately addressed.  I'm sure you can imagine that this does not
> encourage us to invest much more time or effort into providing additional
> feedback.
>
> - R. Niwa
>
>
Ryosuke,

Thanks for your response.

I can definitely appreciate that when you sink time into discussion and
things don't appear to go that way it seems frustrating and doesn't promote
good feelings about investing further.  At the same time, I'm sure you can
appreciate that this leaves things in a frustrating/confusing spot for so
many developers and their orgs around the world because of where this
particular piece of the puzzle lies.  I'm glad to hear that Mozilla's
position/feedback resonates but I'm still unclear.

I have followed all of these discussions pretty closely and even today
after some searching I am not sure about which feedback regarding Shadow
DOM specifically you feel still requires addressing?  Discussion about type
1, 2 boundary seems to have died off - was there some other?  Is there any
hope of resolving that if that's what you mean, or would this require
significant change?

Here's what I actually am unclear on at the end of the day:  Technicalities
around REC or process or politics aside - If we wind up with two
interoperable implementations in FF and Blink, will you still feel there is
something that needs addressing before sending the positive signal that
it'll eventually get implemented in Webkit?  If so, I feel like, as a
developer, now is the time I'd like to learn that.  Just as it is
frustrating to you above - it seems will be all the more frustrating for
everyone if that becomes the case and honestly, the development world is
just guessing what may be wildly uninformed guesses... That seems bad.  If
we need to have hard discussions, let's have them and get it out of the way
even if the result is something somewhat less than a commitment.

That's my 2 cents, anyway.  I'm not the chair, I'm not even a member - it's
just something I hear a lot of people discussing and thought worth bringing
into the open.


Brian Kardell :: @briankardell :: hitchjs.com

[shadow dom] relitigation

[Brian Kardell]

I hate to tear open a wound, but it seems to me that two important browser
vendors have yet to buy into Shadow DOM.  It's currently listed by
Microsoft as "under consideration" but the sense I get is that the signal
isn't very positive right now.  Firefox is planning to move forward, Blink
has it unprefixed.

Things like document.register can be polyfilled fairly well and without too
much crazy.  If imports is controversial or we determine that we need more
experimentation to figure out "what's down there" in terms of other systems
like modules or fetch - we can do a lot of those experiments outside any
browser implementation too and use it to lead discussions.  I am all for
that, especially if we can lead the way in getting vendors to cooperate on
the polyfills and make some efforts to find future safe ways to do this.

But Shadow DOM - this is a different story.  It might not be a fundamental
primitive or DNA level thing, but it's well down there and actually
impossible to polyfill accurately and it is dark, dark magic requiring lots
of code to even fake it reasonably well.  There's a real risk there is that
the fidelity could actually cause problems when you jump to native too, I
think.

There seems to be a pretty large split in sentiment on Shadow DOM, or
perceived sentiment from developers.  From my perspective, a whole lot of
people tell me that they find Shadow DOM one of the most compelling pieces
of custom elements and without it, they're holding off.  Another thing they
tell me that frustrates them is that this makes it hard to share custom
elements - should they assume a Shadow DOM or not.

With Mozilla's post the other day[1] this has opened up a whole lot of new
conversations on my part and the preeminent question seems to be whether
there will be a positive signal from Apple or Microsoft or whether we need
to consider that as good as vapor for now.  For a lot of orgs,
consideration of switching to custom element and their plan for the next
few years is probably affected, as well as the state of the landscape and
where we will be shaping it.

With this in mind, I'm asking if anyone is willing to tip their hand at all
- even to the effect that "if we get two interoperable, unprefixed
versions, we will follow"... Any information I think is helpful - and
asking the question at least might move the conversation forward again (I
hope)?



1 - https://hacks.mozilla.org/2014/12/mozilla-and-web-components/

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

Re: HTML imports in Firefox

[Brian Kardell]

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"  wrote:
>
> On 15 December 2014 at 19:09, Boris Zbarsky  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  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  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: [Push] one or many

[Brian Kardell]

On Thu, Oct 9, 2014 at 2:01 PM, Anne van Kesteren  wrote:
> On Thu, Oct 9, 2014 at 7:53 PM, Brian Kardell  wrote:
>> Can someone clarify why those seem contradictory?  Can a webapp have 1
>> registration, or many?
>
> The term webapp also seems wrong. There's no such established term and
> it does not mean anything in terms of security or typical API/protocol
> boundaries. As far as I can tell you can have a push registration per
> service worker. Which with the current design of service workers means
> push registrations are bound to URL scopes (which in turn are
> origin-scoped).
>
>
> --
> https://annevankesteren.nl/

They do define it in the spec at least[1], but I don't see how it can
mean both things.


[1] http://www.w3.org/TR/push-api/#dfn-webapp

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

[Push] one or many

[Brian Kardell]

I'm really confused by what seems to me like contradictory prose... In
the interface definition it says

"""
Note that just a single push registration is allowed per webapp.
"""

But in multiple places it seems to suggest otherwise, for example, in
the section on uniqueness it says:

"""
webapps that create multiple push registrations are responsible for
mapping the individual registrations to specific app functions as
neces
""

Can someone clarify why those seem contradictory?  Can a webapp have 1
registration, or many?

-Brian

Re: XMLHttpRequest: uppercasing method names

[Brian Kardell]

On Aug 12, 2014 11:12 AM, "Takeshi Yoshino"  wrote:
>
> On Tue, Aug 12, 2014 at 10:55 PM, Anne van Kesteren 
wrote:
>>
>> On Tue, Aug 12, 2014 at 3:37 PM, Brian Kardell 
wrote:
>> > If there's no really good reason to change it, least change is better
IMO
>>
>> All I can think of is that it would be somewhat more consistent to not
>> have this list and always uppercase,
>
>
> Ideally
>
>>
>> but yeah, I guess I'll just align
>> fetch() with XMLHttpRequest.
>
>
> Isn't it an option that we use stricter rule (all uppercase) for the
newly-introduced fetch() API but keep the list for XHR? Aligning XHR and
fetch() is basically good but making fetch() inherit the whitelist is a
little sad.
>
>
>
> Some archaeology:
>
> - Blink recently reduced the whitelist to conform to the latest WHATWG
XHR spec. http://src.chromium.org/viewvc/blink?view=revision&revision=176592
> - Before that, used this list ported to WebKit from Firefox's behavior
http://trac.webkit.org/changeset/13652/trunk/WebCore/xml/xmlhttprequest.cpp
> - Anne introduced the initial version of the part of the spec in Aug 2006
http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest/Overview.html.diff?r1=1.12;r2=1.13;f=h
> -- http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0124.html
> -- http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0126.html
>

fetch should explain magic in XMLHttpRequest et all.. I don't see how it
could differ in the way you are suggesting and match

Re: XMLHttpRequest: uppercasing method names

[Brian Kardell]

On Aug 12, 2014 9:29 AM, "Anne van Kesteren"  wrote:
>
> In https://github.com/slightlyoff/ServiceWorker/issues/120 the
> question came up whether we should perhaps always uppercase method
> names as that is what people seem to expect. mnot seemed okay with
> adding appropriate advice on the HTTP side.
>
> The alternative is that we stick with our current subset and make that
> consistent across APIs, and treat other method names as
> case-sensitive.
>
> I somewhat prefer always uppercasing, but that would require changes
> to XMLHttpRequest.
>
>
> --
> http://annevankesteren.nl/
>

Both seem like common enough answers to this question that I think either
works.  I prefer the later just for consistency sake with xhr and the off
chance that we forgot to consider -something- with a change.  If there's no
really good reason to change it, least change is better IMO

Re: Blocking message passing for Workers

[Brian Kardell]

On Aug 9, 2014 10:16 AM, "David Bruant"  wrote:
>
> Le 09/08/2014 15:51, Alan deLespinasse a écrit :
>
>> Thanks. Apparently I did a lousy job of searching for previous
discussions.
>>
>> I just found this later, longer thread:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html
>> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html
>> (same thread, different year, so they're not linked)
>>
>> Has anything changed since that thread? It seems like the discussion
stalled in early 2012. But I'm glad to find that other people want the same
thing.
>
> This topic is on people minds [1]. My understanding of where we're at is
that "ECMAScript 7" will bring syntax (async/await keywords [2]) that looks
like sync syntax, but acts asynchronously. This should eliminate the need
for web devs for blocking message passing primitives for workers.
>
> There is still a case for blocking primitives for projects that compile
from other languages (C, C++, Python, Java, C#, etc.) to JS [3].
>

I'm glad to be switching last night's twitter discussion to a bigger
medium.  My question here is: what is the proposal (if there is any) to
balance these and simultaneously ensure that we don't wind up limiting
ourselves or providing really bad foot guns or two APIs depending on
whether you're in the main thread or a worker?

> I personally hope it won't happen as it would be a step backwards.
Blocking communication (cross-thread/process/computer) was a mistake. We
need a culture shift. The browser and Node.js are a step in the right
direction (they did not initiate it, but helped popularize it).
>
> David
>
> [1] https://twitter.com/briankardell/status/497843660680351744
> [2] https://github.com/lukehoban/ecmascript-asyncawait#example
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c26
>

Re: =[xhr]

[Brian Kardell]

On Aug 1, 2014 9:52 AM,  wrote:
>
> Thank you for letting me know my input is not desired.
>
As Tab said, you can visually and functionally lock user input in your tab
and even provide a progress meter. Nothing you suggest is difficult with a
sync xhr and promises, and it's less hostile.  How is this unreasonable?

>
> From:"Tab Atkins Jr." 
> To:nmork_consult...@cusa.canon.com,
> Cc:public-webapps 
> Date:08/01/2014 06:46 AM
> Subject:Re: =[xhr]
> 
>
>
>
>
> On Aug 1, 2014 8:39 AM,  wrote:
> >
> > Spinner is not sufficient.  All user activity must stop.  They can take
 a coffee break if it takes too long.  Browser must be frozen and locked
down completely.  No other options are desirable.  All tabs, menus, etc.
must be frozen.  That is exactly the desired result.
>
> By "spinner", I also meant freezing other parts of the page as necessary,
or obscuring them so they can't be clicked.
>
> Asking to freeze the rest of the browser is unnecessary and extremely
user-hostile, and we don't support allowing content to do that.
>
> ~TJ

Re: Fallout of non-encapsulated shadow trees

[Brian Kardell]

[snip]
On Jul 1, 2014 10:07 PM, "Maciej Stachowiak"  wrote:

> (3) A two-way membrane at the API layer between a component and a script;
approximately, this would be the Structured Clone algorithm, but extended
to also translate references to DOM objects between the worlds.

Has this all been spelled out somewhere in more detail and i missed it? In
minutes maybe?  I'm very curious about it, references between worlds could
help in a whole number of ways beyond just this.  If it can be uncovered to
explain the existing platform (or provide a possible explanation) I'd like
to hear more.

Re: [Bug 25376] - Web Components won't integrate without much testing

[Brian Kardell]

On May 23, 2014 10:18 AM, "Tab Atkins Jr."  wrote:
>
> On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen  wrote:
> > I got redirected here from a HTML5 discussion on an 's SEAMLESS
> > attribute:
> >
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376
> >
> > Ian Hickson suggested to publish my findings here so the Web Components
team
> > may consider to re-evaluate the draft and probably amending the spec.
>
> Could you post your findings here?

Replying to the points from the bug, quoted by Tab below ...



>
> Digging through the bug thread, it appears you might be talking about
this:
>
> > Web Components require a plethora of additional browser features and
behaviours.
> >
Natively though, that seems a good thing to me..

> > Web Components require loads of additional HTML, CSS and client script
code for displaying content.
> >
How? CSS seems the same either way, html could actually be significantly
lessened and script is dependent on what you actually want to do.  If it's
just "a fragment" js for a single fragment element would potentially serve
many and you can describe declaratively a lot.


> > Web Components install complex concepts (e.g. ) by
introducing unique, complex, opaque behaviours, abandoning the pure nature
of presentation.

> >
Decorators were dropped last i checked, but many of the new features create
a lightweight alternative to iframes and, again, give us, new powers to
create.


> > Web Components require special script event handling, so existing
script code cannot be reused.

Depends, but possibly.  Can you provide a specific that works better with
iframes in this regard.

> > Web Components require special CSS handling, so existing CSS cannot be
reused.
> >
Same comment as above..



> > Web Components unnecessarily introduce a new clumsy “custom”, or
“undefined” element, leaving the path of presentation. Custom Elements
could as easy be achieved using CSS classes, and querySelector() in ECMA
Script.
> >
Definitely not, because as you say, we add new mechanisms to treat Custom
Elements (note title casing) as first class things with a known lifecycle,
larger meaning etc.  you could visually and interactively achieve similar
results from a user perspective potentially, and nothing prevents you going
forward from maintaining this mentality for your use.  What that approach
doesn't give you is a universal means to declaratively share these with
scores of users who don't have to understand all that and for the community
to participate easily in finding out what actually works for us instead of
spending years in a committee to debate about things only to find out that,
after all, it doesn't.



> > The W3C DOM MutationObserver specification already provides
functionality equivalent to
insertedCallback()/readyCallback()/removeCallback().
>
MutationObservers, I believe, are neutral spec-wise on the point of when
they fire in terms of parsing (I think), but regardless of the spec, at
least Mozilla does not fire them during parse.  That turns out to be a
pretty big deal actually.  Ideally, though, we should be connecting APIs
and layering them atop one another so just because this is possible with
another API does not make it a bad thing.



> Is this correct?  Is this the full list of comments you wish to make?
>
> ~TJ
>

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

[Brian Kardell]

On May 21, 2014 10:29 AM, "Arthur Barstow"  wrote:
>
> On 5/21/14 7:02 AM, Anne van Kesteren wrote:
>>
>> Developers seem to complain about us using mailing lists to
>> communicate rather than GitHub or some other centralized platform that
>> is not email. Might be worth checking with them first.
>
>
> Yes, good point Anne. I tweeted this Q with some tags that were intended
to extend the reach. If others would also reach out, I would appreciate it.
>
> I realize mail lists are a tool and there could be better ones to
reach/engage the developer audience.
>
> -Thanks, AB
>
>
+ public-nextweb...

I've kind of thought of Web Platform Docs as the developer end of things
and w3c specs for implementers and wgs - is it possible to set something up
under that banner? As a developer, i like the push orientation of mailing
lists too, but they suck for lots of other reasons too.

Re: Custom Elements: 'data-' attributes

[Brian Kardell]

On Wed, May 14, 2014 at 7:18 AM, Soledad Penadés  wrote:

[snip]


> And that's where I suggested leaving attribute handling to the component.
> If it "self-registers" as handling a certain attribute, then don't let the
> UA handle it as it would do if unregistered.
>
>
I'm not sure what this means by UA handling, can you explain?  Let me give
you a concrete example and you can tell me what happens.  I work in higher
education, and we have custom elements for things like student's schedules
- showing them, making them, etc.  And we have lists of courses, etc.  Lots
and lots of stuff that has to do with classes (the kind that are taught)
and these classes have unique ids and titles too.  So what happens when I
do:



or



or




These are important things to our component, so, probably I would register
them - but both class and offering mean something as global attributes, and
these are plugged into all sorts of things - CSS, qsa, etc...   When you
say "then don't let the UA handle it as it would do if unregistered" - what
does that mean in this case?  anything?  Would that all still continue to
work?

I'm just trying to understand what you are suggesting there...









>

> --
> //
> // http://soledadpenades.com   //  @supersole //
> // GIF HACKTIVIST // Mozilla Apps Engineering //
>   //
>
>
>
>


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

Re: Custom Elements: 'data-' attributes

[Brian Kardell]

On Thu, May 8, 2014 at 5:37 AM, Anne van Kesteren  wrote:

> On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa  wrote:
> > The answer to that question, IMO, is no.  It's not safe to use custom
> > attributes without 'data-' if one wanted to write a forward compatible
> HTML
> > document.
>
> Note that the question is scoped to custom elements, not elements in
> general.
>
> It seems kind of sucky that if you have already minted a custom
> element name, you still need to prefix all your attributes too.
>
> 
>
> reads a lot better than
>
> 
>
> The clashes are also likely to happen on the API side. E.g. if I mint
> a custom element and support a property named selectable. If that gets
> traction that might prevent us from introducing selectable as a global
> attribute going forward.
>
>
> --
> http://annevankesteren.nl/
>
>
What do the parsing rules say about what an attr may begin with? Is it
plausible to just leading underscore or leading dash them as in CSS so that
all that's really necessary is for HTML to avoid using those natively (not
hard, cause, why would you) and then you provide an easy hatch for good
authors and get decent protection without getting too crazy?


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

Re: [custom-elements] :unresolved and :psych

[Brian Kardell]

On Wed, Mar 26, 2014 at 4:53 PM, Scott Miles  wrote:

> Yes, I agree with what R. Niwa says.
>
> I believe there are many variations on what should happen during element
> lifecycle, and the element itself is best positioned to make those choices.
>
> `:unresolved` is special because it exists a-priori to the element having
> any control.
>
> Scott
>
>
> On Wed, Mar 26, 2014 at 12:26 PM, Ryosuke Niwa  wrote:
>
>> Maybe the problem comes from not distinguishing elements being created
>> and ready for API access versus elements is ready for interactions?
>>
>> I'd also imagine that the exact appearance of a custom element between
>> the time the element is created and the time it is ready for interaction
>> will depend on what the element does.   e.g. img behaves more or less like
>> display:none at least until the dimension is available, and then updates
>> the screen as the image is loaded.  iframe on the other hand will occupy
>> the fixed size in accordance to its style from the beginning, and simply
>> updates its content.
>>
>> Given that, I'm not certain adding another pseudo element in UA is the
>> right approach here.  I suspect there could be multiple states between the
>> time element is created and it's ready for user interaction for some custom
>> elements.  Custom pseudo, for example, seems like a more appealing solution
>> in that regard.
>>
>> - R. Niwa
>>
>> On Mar 25, 2014, at 2:31 PM, Brian Kardell  wrote:
>>
>> I'm working with several individuals of varying skillsets on using/making
>> custom elements - we are using a way cut-back subset of what we think are
>> the really stable just to get started but I had an observation/thought that
>> I wanted to share with the list based on feedback/experience so far...
>>
>> It turns out that we have a lot of what I am going to call "async
>> components" - things that involve calling 1 or more services during their
>> creation in order to actually draw something useful on the screen.  These
>> range from something simple like an RSS element (which, of course, has to
>> fetch the feed) to complex wizards which have to consult a service to
>> determine which view/step they are even on and then potentially additional
>> request(s) to display that view in a good way.  In both of these cases I've
>> seen confusion over the :unresolved pseudo-class.  Essentially, the created
>> callback has happened so from the currently defined lifecycle state it's
>> ":resolved", but still not useful.  This can easily be messed up at both
>> ends (assuming that the thing sticking markup in a page and the CSS that
>> styles it are two ends) such that we get FOUC garbage between the time
>> something is ":resolved" and when it is actually conceptually "ready".  I
>> realize that there are a number of ways to work around this and maybe do it
>> "properly" such that this doesn't happen, but there are an infinitely
>> greater number of ways to barf unhappy content into the screen before its
>> time.  To everyone who I see look at this, it seems they conceptually
>> associate :resolved with "ok it's ready," and my thought is "that isn't
>> necessarily an insensible thing to think since there is clearly a
>> pseudo-class about 'non-readiness' of some kind and nothing else that seems
>> to address this".
>>
>> I see a few options, I think all of them can be seen as enhancements, not
>> necessary to a v1 spec if it is going to hold up something important.   The
>> first would be to let the created callback optionally return a promise - if
>> returned we can delay :resolved until the promise is fulfilled.  The other
>> is to introduce another pseudo like ":loaded" and let the author
>> participate in that somehow, perhaps the same way (optionally return a
>> promise from created).  Either way, it seems to me that if we had that, my
>> folks would use that over the current definition of :resolved in a lot of
>> cases.
>>
>>
>>
>> --
>> Brian Kardell :: @briankardell :: hitchjs.com
>>
>>
>>
>

Just to be clear, so there is no confusion (because I realize after talking
to Dimitri that I was being pretty long winded about what I was saying):
 I'm simply saying what y'all are saying - the element is in the best place
to know that it's really "fully cooked".  Yes, there could be N potential
states between 0 and "fully cooked" too, but we do know (at least I am
seeing repeatedly) that folks would like to participate in saying "ok, now
I am fully cooked" so that the CSS for it can be simple and sensible.

I'm not looking to change anything specifically (except maybe a little more
explicit callout of that in the spec), I'm just providing this feedback so
that we can all think about it in light of other proposals and
conversations we're all having and - maybe - if someone has good ideas you
could share them (offlist if you prefer, or maybe in public-nextweb) so
that those of us who are experimenting can try them out in library space...



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

Re: [custom-elements] :unresolved and :psych

[Brian Kardell]

On Tue, Mar 25, 2014 at 6:27 PM, Dimitri Glazkov wrote:

> Let me try and repeat this back to you, standards-nerd-style:
>
> Now that we have custom elements, there's even more need for notifying a
> style engine of a change in internal elements state -- that is, without
> expressing it in attributes (class names, ids, etc.). We want the ability
> to make custom pseudo classes.
>
> Now, Busta Rhymes-style
>
> Yo, I got change
> In my internal state.
> Style resolution
> It ain't too late.
> We got solution!
> To save our a**ses
> That's right, it's custom pseudo classes.
>
> :DG<
>
>
Probably it comes as no shock that I agree with our want to push Custom
Pseudo-Class forward, and I am *very* pro experimenting in the community
(#extendthewebforward), so - in fact, I am already experimenting with both
Custom Pseudo-Classes in general and this specific case (returning a
promise).  I'm happy to go that route entirely, but I'm sharing because I
am seeing a fair amount of confusion over :unresolved as currently defined.
 In the least case, we might make an effort to spell it out in the spec a
little more and let people know when we talk to them.  Ultimately, from
what I am seeing on the ground, it seems like :loaded or :ready or
something which is potentially component author-informed is actually
actually way more useful a thing for us to wind up with We'll see, I'm
not trying to push it on anyone, I'm just trying to pick the brains of
smart people and provide feedback into the system (tighten the feedback
loop, right).


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

Re: [custom-elements] :unresolved and :psych

[Brian Kardell]

On Tue, Mar 25, 2014 at 6:10 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  Do custom elements present any new challenges in comparison to
> non-custom elements here? I feel like you have the same issue with filling
> a  with data from a remote source.
>
Only really the fact that select exposes no clue already that it isn't
:unresolved or something.  You can see how the hint of an "I'm not ready
yet" can be interpreted this way.  Precisely, if someone created an
 kind of tag, then yes, I do think most people
would think that that indicated when the actual (populated) element was
ready.

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

[custom-elements] :unresolved and :psych

[Brian Kardell]

I'm working with several individuals of varying skillsets on using/making
custom elements - we are using a way cut-back subset of what we think are
the really stable just to get started but I had an observation/thought that
I wanted to share with the list based on feedback/experience so far...

It turns out that we have a lot of what I am going to call "async
components" - things that involve calling 1 or more services during their
creation in order to actually draw something useful on the screen.  These
range from something simple like an RSS element (which, of course, has to
fetch the feed) to complex wizards which have to consult a service to
determine which view/step they are even on and then potentially additional
request(s) to display that view in a good way.  In both of these cases I've
seen confusion over the :unresolved pseudo-class.  Essentially, the created
callback has happened so from the currently defined lifecycle state it's
":resolved", but still not useful.  This can easily be messed up at both
ends (assuming that the thing sticking markup in a page and the CSS that
styles it are two ends) such that we get FOUC garbage between the time
something is ":resolved" and when it is actually conceptually "ready".  I
realize that there are a number of ways to work around this and maybe do it
"properly" such that this doesn't happen, but there are an infinitely
greater number of ways to barf unhappy content into the screen before its
time.  To everyone who I see look at this, it seems they conceptually
associate :resolved with "ok it's ready," and my thought is "that isn't
necessarily an insensible thing to think since there is clearly a
pseudo-class about 'non-readiness' of some kind and nothing else that seems
to address this".

I see a few options, I think all of them can be seen as enhancements, not
necessary to a v1 spec if it is going to hold up something important.   The
first would be to let the created callback optionally return a promise - if
returned we can delay :resolved until the promise is fulfilled.  The other
is to introduce another pseudo like ":loaded" and let the author
participate in that somehow, perhaps the same way (optionally return a
promise from created).  Either way, it seems to me that if we had that, my
folks would use that over the current definition of :resolved in a lot of
cases.



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

Re: [Bug 24823] New: [ServiceWorker]: "MAY NOT" is not defined in RFC 2119

[Brian Kardell]

On Feb 26, 2014 1:01 PM, "Bjoern Hoehrmann"  wrote:
>
> * bugzi...@jessica.w3.org wrote:
> >The section "Worker Script Caching" uses the term "MAY NOT", which is not
> >defined in RFC 2119.  I'm assuming this is intended to be "MUST NOT" or
maybe
> >"SHOULD NOT".
>
> If an agent "MAY $x" then it also "MAY not $x". It is possible that the
> author meant "must not" or "should not" in this specific instance, but
> in general such a reading would be incorrect. If course, specifications
> should not use constructs like "may not".
> --

Your use of "should not" and the logic implies that actually they may use
"may not" they just shouldn't.  Do you mean they may not?

> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: [HTML Imports]: Sync, async, -ish?

[Brian Kardell]

On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald wrote:

> My bad, many apologies. I get what you mean now.
>
> However, if web components are explaining the platform then  is
> :resolved by browser internals (I don't know if this is how :resolved works
> currently). Eg, imagine  as a built-in component which is resolved
> and given a shadow DOM by internals.
>
> 7.2 of custom elements states:

"""
The :unresolved pseudoclass *must* match all custom
elements whose created callback has not yet been invoked.
"""

I suppose this leaves wiggle room that it may actually in theory match on
native elements as well.  As you say, this is a nice explanation maybe for
all elements - though - it doesn't seem remarkable what a custom element
would have something a native wouldn't.  Either way, I think my proposal
holds up in basic theory, the only caveat is whether the thing on body is
just a specialized meaning of "resolved" that only applies to custom
elements, or whether you need a specific name for that thing, right?  It's
really entirely bikesheddable what that thing should be called or maps to -
there must be a name for "the document is done upgrading elements that we
in the tree at parse" - I dont think that is DOMContentLoaded, but
hopefully you take my point.  If we could agree that that solution works,
we could then have a cage match to decide on a good name :)



>
> On 29 January 2014 09:19, Brian Kardell  wrote:
>
>> On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald 
>> wrote:
>>
>>> :unresolved { display: none; } plus "lazyload" (
>>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
>>> would allow devs to create the non-blocking behaviour. But this is the
>>> wrong way around. Devs should have to opt-in to the slow thing and get the
>>> fast thing by default.
>>>
>>>
>> Isn't that what I suggested?  I suggested that it be asyc, just as you
>> said - and that all we do is add the ability to use the :unresolved pseudo
>> class on the body.  This provides authors as a simple means of control for
>> opting out of rendering in blocks above the level of the component without
>> resorting to the need to do it via script or a root level element which
>> serves no other real purpose. This level of ability seems not just simpler,
>> but probably more desirable - like a lot of authors I've done a lot of work
>> with things that pop into existence and cause relayout -- often the thing I
>> want to block or reserve space for isn't the specific content, but a
>> container or something.  Seems to me with addition of a body level
>> :unresolved you could answer pretty much any use case for partial rendering
>> from "just dont do it" all the way to "screw it, the thing pops into
>> existence" (the later being the default) very very simply - and at the
>> right layer (CSS).
>>
>>
>>
>>
>
>


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

Re: [HTML Imports]: Sync, async, -ish?

[Brian Kardell]

On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald wrote:

> :unresolved { display: none; } plus "lazyload" (
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
> would allow devs to create the non-blocking behaviour. But this is the
> wrong way around. Devs should have to opt-in to the slow thing and get the
> fast thing by default.
>
>
Isn't that what I suggested?  I suggested that it be asyc, just as you said
- and that all we do is add the ability to use the :unresolved pseudo class
on the body.  This provides authors as a simple means of control for opting
out of rendering in blocks above the level of the component without
resorting to the need to do it via script or a root level element which
serves no other real purpose. This level of ability seems not just simpler,
but probably more desirable - like a lot of authors I've done a lot of work
with things that pop into existence and cause relayout -- often the thing I
want to block or reserve space for isn't the specific content, but a
container or something.  Seems to me with addition of a body level
:unresolved you could answer pretty much any use case for partial rendering
from "just dont do it" all the way to "screw it, the thing pops into
existence" (the later being the default) very very simply - and at the
right layer (CSS).

Re: [HTML Imports]: Sync, async, -ish?

[Brian Kardell]

On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald wrote:

> (I'm late to this party, sorry)
>
> I'm really fond of the 
> pattern, but I yeah, you could end up with a massive elements list.
>
> How about making link[rel=import] async by default, but make elements with
> a dash in the tagname display:none by default?
>
> On a news article with components, the news article would load, the
> content would be readable, then the components would appear as they load.
> Similar to images without a width & height specified.
>
> As with images, the site developer could apply styling for the component
> roots before they load, to avoid/minimise the layout change as components
> load. This could be visibility:hidden along with a width & height (or
> aspect ratio, which I believe is coming to CSS), or display:block and
> additional styles to provide a view of the data inside the component that's
> good enough for a pre-enhancement render.
>
> This gives us:
>
> * Performance by default (we'd have made scripts async by default if we
> could go back right?)
> * Avoids FOUC by default
> * Can be picked up by a preparser
> * Appears to block rendering on pages that are build with a root web
> component
>
> Thoughts?
>
> Cheers,
> Jake.
>

I think that there are clearly use cases where either way feels "right".
 It's considerably easier to tack on a pattern that makes async "feel" sync
than the reverse.  I'd like to suggest that Jake's proposal is -almost-
really good.  As an author, I'd be happier with the proposal if there were
just a little bit of sugar that made it very very easy to opt in and I
think that this lacks that only in that it relies either on a root level
component or some script to tweak something that indicates the body
visibility or display.  If we realize that this is going to be a common
pattern, why not just provide the simple abstration as part of the system.
 This could be as simple as adding something to section 7.2[1] which says
something like

"""
The :unresolved pseudoclass may also be applied to the body element.  The
body tag is considered :unresolved until all of the elements contained in
the original document have been resolved.  This provides authors a simple
means to additionally manage rendering FOUC including and all the way up to
fully delaying rendering of the page until the Custom Element dependencies
are resolved, while still defaulting to asyc/non-blocking behavior.

Example:
-
/* Apply body styles like background coloring,
but don't render any elements until it's all ready...
*/
body:unresolved * {
display: none;
}
"""

WDYT?


[1] -
http://w3c.github.io/webcomponents/spec/custom/#unresolved-element-pseudoclass



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

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Brian Kardell]

>
>
> As an alternate suggestion, and one that might dodge the subclassing
> issues, perhaps createShadowRoot could take an optional template argument
> and clone it automatically. Then this:
>
> this._root = this.createShadowRoot();
> this._root.appendChild(template.content.cloneNode());
>
> Could turn into this:
>
> this._root = this.createShadowRoot(template);
>
> Which is quite a bit simpler, and involves fewer basic contents.
>
>
Just to be totally clear, you are suggesting that the later would desugar
into precisely the former, correct?  What would happen if you called
createShadowRoot with some other kind of element?

Re: [custom elements] Improving the name of document.register()

[Brian Kardell]

On Dec 13, 2013 3:40 AM, "Maciej Stachowiak"  wrote:
>
>
> Thanks, Google folks, for considering a name to document.register. Though
a small change, I think it will be a nice improvement to code clarity.
>
> Since we're bikeshedding, let me add a few more notes in favor of
defineElement for consideration:
>
> 1) In programming languages, you would normally say you "define" or
"declare" a function, class structure, variable, etc. I don't know of any
language where you "register" a function or class.

My earlier comment/concern about confusion and overloaded terms was about
this exactly.  The language we are in here is js and we define a class
structure by subclassing, right?  The element is defined, its just that
that alone isn't enough - it has to be connected/plugged in to the larger
system by way of a pattern - primarily the parser, right?

>
> 2) registerElement sounds kind of like it would take an instance of
Element and register it for some purpose. defineElement sounds more like it
is introducing a new kind of element, rather than registering a concrete
instance of an element..

I don't disagree with that.  all proposals are partially misleading/not
quite crystal clear IMO.  I don't think registerElement is the height of
perfection either and perhaps reasonable people could disagree on which is
clearer.  At the end of the day I am inclined to not let perfect be the
enemy of good.

> 3) If we someday define a standardized declarative equivalent (note that
I'm not necessarily saying we have to do so right now), defineElement has
more natural analogs. For example, a  or  element would
convey the concept really well. But a  or  or even
 element would be a weird name.
>

Seems a similar problem here - you could be defining anything, plus HTML
already has a dfn...What about ?  That's already on the table
after a lot of discussion I thought - is it not what you meant?

> 4) The analogy to registerProtocolHandler is also not a great one, in my
opinion. First, it has a different scope - it is on navigator and applies
globally for the UI, rather than being on document and having scope limited
to that document. Second, the true parallel to registerProtocolHandler
would be registerElementDefinition. After all, it's not just called
registerProtocol. That would be an odd name. But defineElement conveys the
same idea as registerElementDefinition more concisely. The Web Components
spec itself says "Element registration is a process of adding an element
definition to a registry".

The scope part seems not huge to me... But by the same kind of argument,
you might just as easily make the case that what we are really lacking is a
registry member or something not entirely unlike jQuery's plugins
conceptually.

>
> 5) "Register with the parser" is not a good description of what
document.register does, either. It has an effect regardless of whether
elements are created with the parser. The best description is what the
custom elements spec itself calls it
>
Can you elaborate there?  What effect?  Lifecycle stuff via new?

> I feel that the preference for registerElement over defineElement may
partly be inertia due to the old name being document.register. Think about
it - is registerElement really the name you'd come up with, starting from a
blank slate?

For me, i think it still would be if i wound up with a document level
method as opposed to some other approach like a registry object.  But
again, i am of the opinion that none of these is perfect and to some extent
reasonable people can disagree.. I am largely not trying to convince anyone
that one way is right.  If it goes down as defineElement, the world still
wins IMO.

I hope you will give more consideration to defineElement (which seems to be
the most preferred candidate among the non-register-based names).
>
> Thanks,
> Maciej
>
>
> On Dec 12, 2013, at 10:09 PM, Dominic Cooney  wrote:
>
>>
>>
>>
>> On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell 
wrote:
>>>
>>>
>>> On Dec 11, 2013 11:48 PM, "Ryosuke Niwa"  wrote:
>>> >
>>> >
>>> > On Dec 11, 2013, at 6:46 PM, Dominic Cooney 
wrote:
>>> >
>>> ...
>>> >>> El 11/12/2013 21:10, "Edward O'Connor" 
escribió:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> The name "register" is very generic and could mean practically
anything.
>>> >>>> We need to adopt a name for document.register() that makes its
purpose
>>> >>>> clear to authors looking to use custom elements or those reading
someone
>>> >>>> else's code that makes use of custom elements.
>>&

Re: [custom elements] Improving the name of document.register()

[Brian Kardell]

On Dec 11, 2013 11:48 PM, "Ryosuke Niwa"  wrote:
>
>
> On Dec 11, 2013, at 6:46 PM, Dominic Cooney  wrote:
>
>> On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com 
wrote:
>>>
>>> I have seen registerProtocolHandler() and it's being discused
registerServiceWorker(). I believe registerElementDefinition() or
registerCustomElement() could help to keep going on this path.
>>>
>>> Send from my Samsung Galaxy Note II
>>>
>>> El 11/12/2013 21:10, "Edward O'Connor"  escribió:
>>>
 Hi,

 The name "register" is very generic and could mean practically
anything.
 We need to adopt a name for document.register() that makes its purpose
 clear to authors looking to use custom elements or those reading
someone
 else's code that makes use of custom elements.
>>
>>
>> I support this proposal.
>>

 Here are some ideas:

 document.defineElement()
 document.declareElement()
 document.registerElementDefinition()
 document.defineCustomElement()
 document.declareCustomElement()
 document.registerCustomElementDefinition()

 I like document.defineCustomElement() the most, but
 document.defineElement() also works for me if people think
 document.defineCustomElement() is too long.

>>
>> I think the method should be called registerElement, for these reasons:
>>
>> - It's more descriptive about the purpose of the method than just
"register."
>> - It's not too verbose; it doesn't have any redundant part.
>> - It's nicely parallel to registerProtocolHandler.
>
>
> I'd still refer declareElement (or defineElement) since registerElement
sounds as if we're registering an instance of element with something.
 Define and declare also match SGML/XML terminologies.
>
> - R. Niwa
>

Define/declare seem a little confusing because we are in the imperative
space where these have somewhat different connotations.  It really does
seem to me that conceptually we are registering (connecting the definition)
with the parser or something.  For whatever that comment is worth.

Re: [custom elements] Improving the name of document.register()

[Brian Kardell]

On Wed, Dec 11, 2013 at 3:17 PM, pira...@gmail.com wrote:

> I have seen registerProtocolHandler() and it's being discused
> registerServiceWorker(). I believe registerElementDefinition() or
> registerCustomElement() could help to keep going on this path.
>
>
> Since a custom element is the only kind of element  you could register,
custom seems redundant - similarly - it isn't
registerCustomProtocolHandler().

.registerElement is reasonably short and, IMO, adds the descriptiveness
that Ted is looking for?


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

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Brian Kardell]

+public-nextweb _ i encourage folks there to check out
public-webapps@w3.orgas this conversation is deep and multi-forked and
I am late to the party.

On Dec 7, 2013 4:44 PM, "Brendan Eich"  wrote:
>
> What does polymer do? Cows are already treading paths.
>
> I still smell a chance to do better out of the gate (gave, thanks
autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I
think I taught Yehuda that one) doesn't help. Particular response, please.
>
> /be
>

I think the most important part is to first ensure that we -can- explain
the magic with core apis even if they are initially saltier than we'd all
like.  When reasonable opportunities present themselves to improve
developer ergonomics, we should take them - it doesn't preclude other
opportunities for better flowers to bloom.

The issues in this specific case in my mind surround the observation that
it feels like it is attempting to bind several layers together which are in
various states of "done" and conceptually what we have is more like a
squirrel path than a cow path on this piece.  Without bindings or some kind
of  pattern for solving those use cases, template is a less thing - and i
think we are far from that.Templates aren't necessary for a useful
document.register().  Shadow DOM isn't either but it's more obvious where
the connections are and it seems considerably more stable.  There also
isn't necessarily a 1:1 relationship of component to template, so we have
to be careful there lest we add confusion.  Is this really a ShadowHost?

I am not actually sure that the initial message in this thread really needs
to have anything particular to the template element though, it looks like
the optional third argument could be any Node - and that does actually seem
to describe a useful and common pattern which we could easily explain in
existing terms and it might be fruitful to think about that.

Re: [webcomponents] HTML Imports

[Brian Kardell]

I've been putting off a response on this, but I have some things to add...
The topic on this thread was originally HTML Imports - it seems like some
of the concerns expressed extend beyond imports and are a little wider
ranging.  I am cross posting this comment to public-next...@w3.org as I
think it is related.

I share the concern about letting out an API too early, but I think my
concerns are different.  In the past we worked (meaning browsers, devs,
stds groups) in a model in which things were released into the wild -
prefixed or not - without a very wide feedback loop.  At that point, the
practical realities leave not many good options for course correction or
even for small, but significant tweaks.  I think a lot is happening to
change that model and, as we can see in the case of everything with Web
Components (esp imports and selectors perhaps) the wider we throw the net
the more feedback we get from real people trying to accomplish real things
with real concerns - not just theory.  Some of this experimentation is
happening in the native space, but it is behind a flag, so we are shielded
from the problems above - no public Web site is relying on those things.
 And some of that is happening in the prollyfill space - Github FTW - in
projects like x-tags and polymer.  When we really look down through things
it does feel like it starts to become clear where the pain points are and
where things start to feel more stable.  With this approach, we don't need
to "rush" standardization in the large scale - if we can reasonably do it
without that and there seems to be wide questioning - let's hold off a bit.

HTML Imports, for example, are generating an *awful* lot of discussion - it
feels like they aren't cooked to me.  But virtually every discussion
involves elements we know we'd need to experiment in that space - modules
would allow one kind of experimentation, promises seem necessary for other
kinds, and so on.  There is a danger of undercooking, yes - but there is
also a danger in overcooking in the standards space alone that I think is
less evident:  No matter how good or bad something is technically, it needs
uptake to succeed.  If you think that ES6 modules have absolutely nothing
to do with this, for example, but through experimentation in the community
that sort of approach turns out to be a winner - it is much more valuable
than theoretical debate.  Debate is really good - but the advantage I think
we need to help exploit is that folks like Steve Souders or James Burke and
W3C TAG can debate and make their cases with working code without pulling
the proverbial trigger if we prioritize the right things and tools to make
it possible.  And no ones code needs to break in the meantime - the
JS-based approach you use today will work just as well tomorrow - better
actually because the perf curve of the browser and speed of machines they
run on is always up.

I don't think that "perfect" imports is necessarily the lynch-pin to value
in Web Components - it needn't block other progress to slow down the
standard on this one.  Other things like document.register already feel a
lot more stable.  Finding a way to evolve the Web is tricky, but I think
doable and the Web would be a lot better for it if we can get it right.

Re: [HTML Imports]: what scope to run in

[Brian Kardell]

On Nov 19, 2013 2:22 AM, "Ryosuke Niwa"  wrote:
>
>
> On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov 
wrote:
>
>> On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa  wrote:
>>>
>>> We share the concern Jonas expressed here as I've repeatedly mentioned
on another threads.
>>>
>>> On Nov 18, 2013, at 4:14 PM, Jonas Sicking  wrote:

 This has several downsides:
 * Libraries can easily collide with each other by trying to insert
 themselves into the global using the same property name.
 * It means that the library is forced to hardcode the property name
 that it's accessed through, rather allowing the page importing the
 library to control this.
 * It makes it harder for the library to expose multiple entry points
 since it multiplies the problems above.
 * It means that the library is more fragile since it doesn't know what
 the global object that it runs in looks like. I.e. it can't depend on
 the global object having or not having any particular properties.
>>>
>>>
>>> Or for that matter, prototypes of any builtin type such as Array.
>>>
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.
>>>
>>>
>>> IMO, this is the biggest problem.
>>>
 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.
>>>
>>>
>>> Indeed.
>>>
 At the very least, I would like to see a way to write your
 HTML-importable document as a module. So that it runs in a separate
 global and that the caller can access exported symbols and grab the
 ones that it wants.

 Though I would even be interested in having that be the default way of
 accessing HTML imports.
>>>
>>>
>>> Yes!  I support that.
>>>
 I don't know exactly what the syntax would be. I could imagine
something like

 In markup:
 

 Once imported, in script:
 new $('mylib').import.MyCommentElement;
 $('mylib').import.doStuff(12);

 or

 In markup:
 

 Once imported, in script:
 new MyCommentElement;
 doStuff(12);
>>>
>>>
>>> How about this?
>>>
>>> In the host document:
>>> 
>>> 
>>> foo1.bar();
>>> foo2();
>>> 
>>>
>>> In foo.js:
>>> module foo1 {
>>> export function bar() {}
>>> }
>>> function foo2() {}
>>
>>
>> I think you just invented the  element:
https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples
>
>
> Putting the backward compatibility / fallback behavior concern with
respect to the HTML parsing algorithm aside, the current proposal appears
to only support js files.  Are you proposing to extend it so that it can
also load HTML documents just like link[rel=import] does?
>

I think james burke purposes something to that effect
https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is in
reply to me, comment #4 if i understand the question)

Re: [HTML Imports]: Sync, async, -ish?

[Brian Kardell]

Mixed response here...

>> I love the idea of making HTML imports *not* block rendering as the
default behavior
In terms of custom elements, this creates as a standard, the dreaded FOUC
problem about which a whole different group of people will be blogging and
tweeting... Right?  I don't know that the current solution is entirely
awesome, I'm just making sure we are discussing the same fact.  Also, links
in the head and links in the body both "work" though the spec disallows the
later it is defacto - the former blocks, the later doesn't I think.
 This creates some interesting situations for people that use something
like a CMS where they don't get to own the head upfront.

> So, for what it's worth, the Polymer team has the exact opposite
desire. I of course acknowledge use cases
> where imports are being used to enhance existing pages, but the assertion
that this is the primary use case is > at least arguable.

Scott, is that because of what I said above (why polymer has the exact
opposite desire)?

>  if we allow "Expressing the dependency in JS" then why doesn't 'async'
(or 'sync') get us both what we want?

Just to kind of flip this on its head a bit - I feel like it is maybe
valuable to think that we should worry about how you express it in JS
*first* and worry about declarative sugar for one or more of those cases
after.  I know it seems the boat has sailed on that just a little with
imports, but nothing is really final else I think we wouldnt be having this
conversation in the first place.  Is it plausible to excavate an
explantation for the imports magic and define a JS API and then see how we
tweak that to solve all the things?

Re: Making selectors first-class citizens

[Brian Kardell]

On Mon, Sep 16, 2013 at 4:29 PM, Tab Atkins Jr. wrote:

> On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell  wrote:
> >> If they didn't support down-level browsers at all, then they're
> >> already broken for a lot of users, so making them broken for a few
> >> more shouldn't be a huge deal. ^_^
> >
> > This seems like a cop out if there is an easy way to avoid breaking them.
> > Just leaving the prefixed ones there goes a long way, but I think we've
> > shown that some libs and uses either happened before the decision to
> switch
> > to .matches so they forward estimated that it would be .matchesSelector
> and,
> > people used them (or maybe they've used them before the lib was updated
> > even).  It seems really easy to unprefix matchesSelector, and say "see
> > matches, it's an alias" and prevent breakage.  If I'm alone on that, I'm
> not
> > going to keep beating it to death, it just seems easily forward
> friendly.  I
> > know I've gotten calls for some mom and pop type project where I guessed
> > wrong on early standards in my younger days and, well - it sucks.  I'd
> > rather not put anyone else through that pain unnecessarily if there is a
> > simple fix.  Maybe I am wrong about the level of simplicity, but - it
> seems
> > really bikesheddy anyway.
>
> Aliasing cruft is *often* very simple to add; that's not the point.
> It's *cruft*, and unnecessary at that.  Aliasing is sometimes a good
> idea, if you have a well-supported bad name and there's a really good
> alternate name you want to use which is way more consistent, etc.
> This isn't the case here - you're suggesting we add an alias for a
> term that *doesn't even exist on the platform yet*.



I feel like you are taking it to mean that I am advocating aliasing
everywhere for everything where that is not simply not my intent.  I am
saying in this one very particular case because of the timing of things it
seems like it would be a good idea to alias and be done with it.


> There are
> literally zero scripts which depend on the name "matchesSelector",
> because it's never worked anywhere.  They might depend on the prefixed
> variants, but that's a separate issue to deal with.
>
>
I think Francois shared a github search with shows almost 15,500 uses
expecting matchesSelector.  I think we all agree these should work just
fine as long as prefixes remain - but that's the point... With that many,
why worry about when someone wrote their code or unprefixing or lots more
emails.  Seems an acceptable amount of cruft to me in this case.  Having
said that, I promise I will make no further case :)




> ~TJ
>



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

Re: Making selectors first-class citizens

[Brian Kardell]

On Mon, Sep 16, 2013 at 5:43 PM, Scott González wrote:

> On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell  wrote:
>
>> I think Francois shared a github search with shows almost 15,500 uses
>> expecting matchesSelector.
>>
>
> As is generally the case, that GitHub search returns the same code
> duplicated thousands of times. From this search, it's impossible to tell
> which are forks of libraries implementing a polyfill or shim, which are
> projects that actually get released, which are projects that will never be
> released, and which will update their dependencies in a timely fashion
> (resulting in use of the proper method). It seems like a fair amount of
> these are actually just a few polyfills or different versions of jQuery.
> These results are also inflated by matches in source maps.
>


That's a good observation.  I hadn't considered that.

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

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 16, 2013 3:46 PM, "Tab Atkins Jr."  wrote:
>
> On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell 
wrote:
> > I think the responses/questions are getting confused.  I'm not sure
about
> > others, but my position is actually not that complicated:  This feature
has
> > been out there and interoperable for quite a while - it is prefixed
> > everywhere and called matchesSelector.
>
> No, it's called *MatchesSelector, where * is various vendor prefixes.
>
Yeah, that is more accurately what I intended to convey - the delta being
the selector part.

> > Some potentially significant group
> > of people assumed that when it was unprefixed it would be called
"matches"
> > and others "matchesSelector".
>
> Regardless of what they assumed, there's presumably a case to handle
> older browsers that don't support it at all.  If the scripts guessed
> wrongly about what the unprefixed name would be, then they'll fall
> into this case anyway, which should be okay.
>
Yes, as long as prefixes stay around, and we don't change repurpose
.matches for another use  that's true.  I thought someone suggested the
later earlier in the thread(s) have to go back and look.

> If they didn't support down-level browsers at all, then they're
> already broken for a lot of users, so making them broken for a few
> more shouldn't be a huge deal. ^_^
>
This seems like a cop out if there is an easy way to avoid breaking them.
 Just leaving the prefixed ones there goes a long way, but I think we've
shown that some libs and uses either happened before the decision to switch
to .matches so they forward estimated that it would be .matchesSelector
and, people used them (or maybe they've used them before the lib was
updated even).  It seems really easy to unprefix matchesSelector, and say
"see matches, it's an alias" and prevent breakage.  If I'm alone on that,
I'm not going to keep beating it to death, it just seems easily forward
friendly.  I know I've gotten calls for some mom and pop type project where
I guessed wrong on early standards in my younger days and, well - it sucks.
 I'd rather not put anyone else through that pain unnecessarily if there is
a simple fix.  Maybe I am wrong about the level of simplicity, but - it
seems really bikesheddy anyway.

> ~TJ

Re: Making selectors first-class citizens

[Brian Kardell]

On Mon, Sep 16, 2013 at 2:51 PM, Ryosuke Niwa  wrote:

> On Sep 13, 2013, at 8:26 PM, Brian Kardell  wrote:
>
>
> On Sep 13, 2013 4:38 PM, "Ryosuke Niwa"  wrote:
> >
> >
> > On Sep 11, 2013, at 11:54 AM, Francois Remy  wrote:
> >
> >> For the record, I'm equally concerned about renaming `matchesSelector`
> into `matches`.
> >>
> >> A lot of code now rely on a prefixed or unprefixed version of
> `matchesSelector` as this has shipped in an interoperable fashion in all
> browsers now.
> >
> >
> > Which browser ships matchesSelector unprefixed?
> > Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed.
> >
> >
> > On Sep 13, 2013, at 1:12 PM, Francois Remy  wrote:
> >
> >>>> A lot of code now rely on a prefixed or unprefixed version of
> >>>> `matchesSelector` as this has shipped in an interoperable fashion in
> all
> >>>> browsers now.
> >>>
> >>>
> >>> Unprefixed?
> >>
> >>
> >> Yeah. Future-proofing of existing code, mostly:
> >>
> >>
> >>
> https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref
> >> =searchresults
> >
> >
> > That’s just broken code.  One cannot speculatively rely on unprefixed
> DOM functions until they’re actually spec’ed and shiped.
> > I have no sympathy or patience to maintain the backward compatibility
> with the code that has never worked.
> >
>
> I am not really sure why you feel this way - this piece of the draft is
> tremendously stable, and interoperable as anything else.
>
> It's not interoperable at all. No vendor has ever shipped matchesSelector
> unprefixed as far as I know.  i.e. it didn't work anywhere unless you
> explicitly relied upon prefixed versions.
>
> Prefixes bound to vendors which may or may not match final and may or may
> not disappear when final comes around or just whenever, in release channel
> is exactly why most people are against this sort of thing now.  This
> predates that shift and regardless of whether we like it, stuff will break
> for people who were just following examples and going by the
> implementation/interop and  standard perception of stability.  Websites
> will stop working correctly - some will never get fixed - others will waste
> the time of hundreds or thousands of devs...
>
> Anyone using the prefixed versions should have a fallback path for old
> browsers that doesn't support it.  If some websites will break, then we'll
> simply keep the old prefixed version around but this is essentially each
> vendor's decision.  Gecko might drop sooner than other vendors for example.
>
> So.. Ok to keep prefix working in all browsers, but not just add it?  For
> the most part, isn't that just like an alias?
>
> Whether a browser keeps a prefixed version working or not is each vendor's
> decision.  Given that the unprefixed version has never worked, I don't see
> why we want to use the name matchesSelector as opposed to matches.
>
> - R. Niwa
>
>

I think the responses/questions are getting confused.  I'm not sure about
others, but my position is actually not that complicated:  This feature has
been out there and interoperable for quite a while - it is prefixed
everywhere and called matchesSelector.  Some potentially significant group
of people assumed that when it was unprefixed it would be called "matches"
and others "matchesSelector".  Whatever we think people should do in terms
of whether there is a fallback or what not, we know reality often doesn't
match that - people support a certain version forward.  However much we'd
like people to switch, lots of websites are an investment that doesn't get
revisited for a long time.  Thus: 1) let's not try to repurpose matches for
anything that doesn't match this signature (I thought I heard someone
advocating that early on) 2) let's make sure we don't disable those
prefixes and risk breaking stuff that assumed improperly ~or~ if possible -
since this is so bikesheddy, let's just make an alias in the spec given the
circumstances.



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

Re: should mutation observers be able to observe work done by the html parser

[Brian Kardell]

was therw ever agreement on this old topic?
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0618.htmlwhether
by de facto implementation or spec agreements?  I am not seeing
anything in the draft but maybe i am missing it...

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 14, 2013 6:07 AM, "Anne van Kesteren"  wrote:
>
> On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell  wrote:
> > I am not really sure why you feel this way - this piece of the draft is
> > tremendously stable, and interoperable as anything else.  The decision
to
> > make it matches was old and popular.  It's not just random joe schmoe
doing
> > this, it's illustrated and recommended by respected sources... For
example
> > http://docs.webplatform.org/wiki/dom/methods/matchesSelector
>
> 1) I don't think that's a respected source just yet. 2) When I search
> for matchesSelector on Google I get
> https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which
> reflects the state of things much better. Note that the name
> matchesSelector has been gone from the standard for a long time now.
>
>
> > So.. Ok to keep prefix working in all browsers, but not just add it?
 For
> > the most part, isn't that just like an alias?
>
> Depends on the implementation details of the prefixed version. FWIW,
> I'd expect Gecko to remove support for the prefixed version. Maybe
> after some period of emitting warnings. We've done that successfully
> for a whole bunch of things.
>
>
> --
> http://annevankesteren.nl/

I think there may be confusion because of where in the thread i responded -
it was unclear who i was responding to (multi).  I pointed to web platform
link because it is an example of a respected source: a) showing "how to
write it for forward compat" b) assuming that, based on old/popular
decision it would be called matches.

I didnt use the moz ref because i think it is misleading in that: a) unlike
a *lot* of other moz refs, it doesn't show anything regarding using it with
other prefixes/unprefixing b) the state of that doc now still wouldn't be
what someone referenced in a project they wrote 6 months or a year ago.

My entire point is that it seems, unfortunately, in this very specific
case, kind of reasonable that:
A) Element.prototype.matches() has to mean what .mozMatchedSelector() means
today.  It shouldn't be reconsidered, repurposed or worrisome.
B) Enough stuff assumes Element.prototype.matchesSelector() to cause me
worry that it will prevent unprefixing.
C) We could bikeshed details all day long, but why not just add both where
one is an alias for the other.  Then, what Anne said about dropping prefix
over time becomes less troubling as the number of people who did neither
and don't rev becomes vanishingly small (still, if it is easy why drop at
all).

Very succinctly, i am suggesting:
.matchesSector be unprefixed, .matches is an alias and docs just say "see
matchesSelector, its an alias." And no one breaks.  And we avoid this in
the future by following better practices.

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 13, 2013 4:38 PM, "Ryosuke Niwa"  wrote:
>
>
> On Sep 11, 2013, at 11:54 AM, Francois Remy  wrote:
>
>> For the record, I'm equally concerned about renaming `matchesSelector`
into `matches`.
>>
>> A lot of code now rely on a prefixed or unprefixed version of
`matchesSelector` as this has shipped in an interoperable fashion in all
browsers now.
>
>
> Which browser ships matchesSelector unprefixed?
> Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed.
>
>
> On Sep 13, 2013, at 1:12 PM, Francois Remy  wrote:
>
 A lot of code now rely on a prefixed or unprefixed version of
 `matchesSelector` as this has shipped in an interoperable fashion in
all
 browsers now.
>>>
>>>
>>> Unprefixed?
>>
>>
>> Yeah. Future-proofing of existing code, mostly:
>>
>>
>>
https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref
>> =searchresults
>
>
> That’s just broken code.  One cannot speculatively rely on unprefixed DOM
functions until they’re actually spec’ed and shiped.
> I have no sympathy or patience to maintain the backward compatibility
with the code that has never worked.
>

I am not really sure why you feel this way - this piece of the draft is
tremendously stable, and interoperable as anything else.  The decision to
make it matches was old and popular.  It's not just random joe schmoe doing
this, it's illustrated and recommended by respected sources... For example
http://docs.webplatform.org/wiki/dom/methods/matchesSelector

Essentially, this reaches the level of de facto standard in my book. .all
it really lacks is a vote.

Prefixes bound to vendors which may or may not match final and may or may
not disappear when final comes around or just whenever, in release channel
is exactly why most people are against this sort of thing now.  This
predates that shift and regardless of whether we like it, stuff will break
for people who were just following examples and going by the
implementation/interop and  standard perception of stability.  Websites
will stop working correctly - some will never get fixed - others will waste
the time of hundreds or thousands of devs... This isn't something that was
implemented by 1 or 2 browsers, was hotly contested or has only been around
a few months: This is out there a long time and implemented a long time.

> Furthermore, the existing code will continue to work with the prefixed
versions since we’re not suggesting to drop the prefixed versions.
>
But, you could just as easily because it is prefixed and experimental.  I
guess i am just not understanding why we are ok to keep around the crappy
named prefix ones but not alias the better name that is widely documented
and definitely used just so we can bikeshed a bit more?  If there is also
something better, let's find a way to add without needing to mess with this.

> - R. Niwa
>

So.. Ok to keep prefix working in all browsers, but not just add it?  For
the most part, isn't that just like an alias?

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 12, 2013 2:16 AM, "Garrett Smith"  wrote:
>
> FWD'ing to put my reply back on list (and to others)...
>
> On Sep 11, 2013 6:35 AM, Anne van Kesteren  wrote:
>
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have
>
> var sel = new Selectors("i > love > selectors, so[much]")
> sel.test(node)
>
> # 2007 David Anderson proposed the idea.
>
> That seems like a much nicer approach.
>
> (It also means this can be neatly defined in the Selectors
> specification, rather than in DOM, which means less work for me. :-))
>
> # 2009 the API design remerged
> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1445.html
>
> # 2010 Selectors explained in an article:
> http://www.fortybelow.ca/hosted/dhtmlkitchen/JavaScript-Query-Engines.html
> (search Query Matching Strategy).
> --
> Garrett
> Twitter: @xkit
> personx.tumblr.com
>


I may be the only one, but... I am unsure what you are advocating here
Garrett.

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 11, 2013 10:04 AM, "Robin Berjon"  wrote:
>
> On 11/09/2013 15:56 , Anne van Kesteren wrote:
>>
>> On Wed, Sep 11, 2013 at 2:52 PM, Brian Kardell 
wrote:
>>>
>>> I like the idea, but matches has been in release builds for a long time,
>>> right?  Hitch uses it.
>>
>>
>> .w("matches" in document.body)
>> http://software.hixie.ch/utilities/js/live-dom-viewer/
>>
>> false in both Firefox and Chrome.
>
>
> See http://caniuse.com/#search=matches. You do get mozMatchesSelector
(and variants) in there.
>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

Yes, to be clear, that is what i meant. If it is in a draft and
widely/compatibly implemented and deployed in released browsers not behind
a flag - people are using it.  That's part of why we switched the general
philosophy right? No doubt one can be a shorthand for the better approach
though...right?

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 11, 2013 12:29 PM, "Boris Zbarsky"  wrote:
>
> On 9/11/13 12:26 PM, Brian Kardell wrote:
>>
>> If something with the same name but different
>> signature or functionality goes out unprefixed, things will break.
>
>
> Why is this, exactly?  Is code assuming that "mozFoo", "webkitFoo" and
"foo" are interchangeable?  Because they sure aren't, in general.
>

> In any case, there is no "mozMatches" or "webkitMatches", so "matches"
should be ok.


As things mature to the manner/degree i described, yes.  But, this isn't
surprising, right?  When things reach this level, we feel pretty
comfortable calling them polyfills which do exactly what you describe: We
assume prefixed and unprefixed are equivalent.  We also feel comfortable
listing them on sites like caniuse.com and even working group members have
products that effectively just unprefix.  It's the same logic used by
Robert O'Callahan regarding unprefixing CSS selectors[1] and we ended up
doing a lot of that - and even prior to that there was talk of unprefixing
.matchesSelector as .matches right here on public web-apps[2].  When things
reach this point, we really have to consider what is out there and how
widely it has been promoted for how long.  I think it is too late for
matchesSelector for sure, and I'd be lying if I said I wasn't worried about
.matches().  I for one am very glad we are taking approaches that help us
not be in this boat - but the idea that something can be called as a
constructor or not isn't new either - can we make it backwards compat and
get the best of both worlds?  Given the similarities in what they do, it
doesn't seem to me like implementation is a problem.  In the very least, I
feel like we need to retain .matchesSelector for some time.

[1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0271.html

[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1146.html

>
> -Boris
>
>

Re: Making selectors first-class citizens

[Brian Kardell]

On Wed, Sep 11, 2013 at 12:26 PM, Brian Kardell  wrote:

>
> On Sep 11, 2013 11:11 AM, "James Graham"  wrote:
> >
> > On 11/09/13 15:50, Brian Kardell wrote:
> >
> >> Yes, to be clear, that is what i meant. If it is in a draft and
> >> widely/compatibly implemented and deployed in released browsers not
> >> behind a flag - people are using it.
> >
> >
> > If people are using a prefixed — i.e. proprietary — API there is no
> requirement that a standard is developed and shipped for that API. It's
> then up to the individual vendor to decide whether to drop their
> proprietary feature or not.
> >
> >
>
> Please note carefully what i said.  I don't think I am advocating anything
> that hasn't been discussed a million times.  In theory what you say was the
> original intent.  In practice, that's not how things went.  Browsers have
> changed what used to be standard practice to help avoid this in the
> future.  We are making cross-browser prollyfills outside browser
> implementations to avoid this in the future.  What is done is done though.
> The reality is that real and not insignificant production code uses
> prefixed things that meet the criteria I stated.  If removed, those will
> break.  If something with the same name but different signature or
> functionality goes out unprefixed, things will break.
>

Mozillians, just for example:
https://github.com/x-tag/x-tag/blob/master/dist/x-tag-components.js#L2161

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

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 11, 2013 11:11 AM, "James Graham"  wrote:
>
> On 11/09/13 15:50, Brian Kardell wrote:
>
>> Yes, to be clear, that is what i meant. If it is in a draft and
>> widely/compatibly implemented and deployed in released browsers not
>> behind a flag - people are using it.
>
>
> If people are using a prefixed — i.e. proprietary — API there is no
requirement that a standard is developed and shipped for that API. It's
then up to the individual vendor to decide whether to drop their
proprietary feature or not.
>
>

Please note carefully what i said.  I don't think I am advocating anything
that hasn't been discussed a million times.  In theory what you say was the
original intent.  In practice, that's not how things went.  Browsers have
changed what used to be standard practice to help avoid this in the
future.  We are making cross-browser prollyfills outside browser
implementations to avoid this in the future.  What is done is done though.
The reality is that real and not insignificant production code uses
prefixed things that meet the criteria I stated.  If removed, those will
break.  If something with the same name but different signature or
functionality goes out unprefixed, things will break.

Re: Making selectors first-class citizens

[Brian Kardell]

On Sep 11, 2013 9:34 AM, "Anne van Kesteren"  wrote:
>
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have this:
>
>   var sel = new Selectors("i > love > selectors, so[much]")
>   sel.test(node)
>
> That seems like a much nicer approach.
>
> (It also means this can be neatly defined in the Selectors
> specification, rather than in DOM, which means less work for me. :-))
>
>
> --
> http://annevankesteren.nl/
>

I like the idea, but matches has been in release builds for a long time,
right?  Hitch uses it.

Re: [webcomponents]: The Shadow Cat in the Hat Edition

[Brian Kardell]

On Sep 9, 2013 9:32 PM, "Tab Atkins Jr."  wrote:
>
> On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles  wrote:
> >>> I'd greatly prefer to stick with the current plan of having to mark
> >>> things to be exposed explicitly,
> >
> > Fwiw, we tried that and got in the weeds right away. See Dimitri's post
for
> > details. I'm afraid of trading real-life pain (e.g. exploding part
lists)
> > for what is IMO an unreal advantage (e.g. the notion components can be
> > upgraded and assured never to break is just not realistic).
>
> Did you miss my suggestion that we allow this with a third value on
> the current "allow selectors through" switch?
>
> ~TJ
>

I am worried that i am not understanding one or both of you properly and
honestly ... I am feeling just a bit lost.

For purposes here consider i have some kind of a special table component
complete with sortable and configurable columns.  When i use that, i
honestly don't want to know what is in the sausage - just how to style or
potentially deal with some parts.  If i start writing things depending on
the gory details, shame on me.  If you leave me no choice but to do that,
shame on you.  You can fool me once but you can't get fooled again... Or
something.

Ok, so, is there a problem with things at that simple level or do the
problems only arise as i build a playlist component out of that table and
some other stuff and in turn a music player out of that?  Is that the
exploding parts list?  Why is exposing explicitly bad?

Re: Needs A Beauty Nap

[Brian Kardell]

On Tue, Aug 13, 2013 at 9:15 AM, Daniel Buchner  wrote:

> I concur. On hold doesn't mean forever, and the imperative API affords us
> nearly identical feature capability. Nailing the imperative and getting the
> APIs to market is far more important to developers at this point.
> On Aug 12, 2013 4:46 PM, "Alex Russell"  wrote:
>
>> As discussed face-to-face, I agree with this proposal. The declarative
>> form isn't essential to the project of de-sugaring the platform and can be
>> added later when we get agreement on what the right path forward is.
>> Further,  is evidence that it's not even necessary so long
>> as we continue to have the plumbing for loading content that is HTML
>> Imports.
>>
>> +1
>>
>>
>> On Mon, Aug 12, 2013 at 4:40 PM, Dimitri Glazkov wrote:
>>
>>> tl;dr: I am proposing to temporarily remove declarative custom element
>>> syntax (aka ) from the spec. It's broken/dysfunctional as
>>> spec'd and I can't see how to fix it in the short term.
>>>
>>> We tried. We gave it a good old college try. In the end, we couldn't
>>> come up with an  syntax that's both functional and feasible.
>>>
>>> A functional  would:
>>>
>>> 1) Provide a way to declare new or extend existing HTML/SVG elements
>>> using markup
>>> 2) Allow registering prototype/lifecycle callbacks, both inline and out
>>> 3) Be powerful enough for developers to prefer it over document.register
>>>
>>> A feasible  would:
>>>
>>> 1) Be intuitive to use
>>> 2) Have simple syntax and API surface
>>> 3) Avoid complex over-the-wire dependency resolution machinery
>>>
>>> You've all watched the Great Quest unfold over in public-webapps over
>>> the last few months.
>>>
>>> The two key problems that still remain unsolved in this quest are:
>>>
>>> A. How do we integrate the process of creating a custom element
>>> declaration [1] with the process of creating a prototype registering
>>> lifecycle callbacks?
>>>
>>> B. With HTML Imports [2], how do we ensure that the declaration of a
>>> custom element is loaded after the declaration of the custom element
>>> it extends? At the very least, how do we enable developers to reason
>>> about dependency failures?
>>>
>>> We thought we solved problem A first with the "incredible this" [3],
>>> and then with the "last completion value" [4], but early experiments
>>> are showing that this last completion value technique produces brittle
>>> constructs, since it forces specific statement ordering. Further, the
>>> technique ties custom element declaration too strongly to script. Even
>>> at the earliest stages, the developers soundly demanded the ability to
>>> separate ALL the script into a single, separate file.
>>>
>>> The next solution was to invent another quantum of time, where
>>>
>>> 1) declaration and
>>> 2) prototype-building come together at
>>> 3) some point of registration.
>>>
>>> Unfortunately, this further exacerbates problem B: since (3) occurs
>>> neither at (1) or (2), but rather at some point in the future, it
>>> becomes increasingly more difficult to reason about why a dependency
>>> failed.
>>>
>>> Goram! Don't even get me started on problem B. By far, the easiest
>>> solution here would have been to make HTML Imports block on loading,
>>> like scripts. Unlucky for us, the non-blocking behavior is one of the
>>> main benefits that HTML Imports bring to the table. From here, things
>>> de-escalate quickly. Spirits get broken and despair rules the land.
>>>
>>> As it stands, I have little choice but to make the following proposal:
>>>
>>> Let's let declarative custom element syntax rest for a while. Let's
>>> yank it out of the spec. Perhaps later, when it eats more cereal and
>>> gathers its strength, it shall rise again. But not today.
>>>
>>> :DG<
>>>
>>> [1]:
>>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-create-custom-element-declaration
>>> [2]:
>>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html
>>> [3]:
>>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0152.html
>>> [4]:
>>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-last-completion-value
>>>
>>>
>>

+1 - this is my preferred route anyway.  Concepts like register and shadow
dom are the core elements... Give projects like x-tags and polymer and even
projects like Ember and Angular some room to help lead the charge on asking
those questions and helping to offer potentially competing answers -- there
need be no rush to standardize at the high level at this point IMO.

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

Re: jar protocol

[Brian Kardell]

>> I'm not sure it matters, I suppose it depends on:
>>
>> a) where the link tag will be allowed to live
>
>
> You can use  anywhere. It might not be valid, but who cares about
> validity :) It works.
>
Some people :)  why does it have to be invalid when it works.  Lame, no?

>
>> b) the effects created by including the same link href multiple times in
>> the same doc
>
> No effect whatsoever beyond wasted resources.
>
Yeah, if a UA mitigated that somehow it would address this pretty well.  It
should be cached the second time i suppose, but there has to be overhead in
re-treating as a fresh request.  Maybe they are smart enough to deal with
that already.
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

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

Re: jar protocol

[Brian Kardell]

>

> Can you hash out a little bit more how this would work? I'm assuming you
mean something like:
>
>   
>
Meh, sorta - but I was missing some context on the mitigation strategies -
thanks for filling me in offline.

Still, same kinda idea, could you add an attribute that allowed for it to
specify that it is available in a bundle?  I'm not suggesting that this is
fully thought out, or even necessarily useful, just fleshing out the
original question in a potentially more understandable/acceptable way...

  

That should be pretty much infinitely back-compatible, and require no
special mitigation at the server (including configuration wise which many
won't have access to) - just that they share the root concept and don't
clash, which I think is implied by the server solution too, right?  Old UAs
would ignore the unknown bundle attribute and request the src as per usual.
 New UAs could make sure that an archive was requested only once and serve
the file out of the archive.  Presumably you could just add support into
that attribute for some simple way to indicate a named link too...

Psuedo-ish code, bikeshed details, this is just to convey idea:

   


I don't know if this is wise or useful, but one problem that I run into
frequently is that I see pages that mash together content where the author
doesn't get to control the head... This can make integration a little
harder than I think it should be. I'm not sure it matters, I suppose it
depends on:

a) where the link tag will be allowed to live

b) the effects created by including the same link href multiple times in
the same doc

This might be entirely sidetracking the main conversation, so I don't want
to lose that I really like where this is going so far sans any of my
questions/comments :)

Re: jar protocol

[Brian Kardell]

Would it be possible (not suggesting this would be the  common story) to
reference a zipped asset directly via the full url, sans a link tag?

Re: URL comparison

[Brian Kardell]

+ the public-nextweb list...

On Wed, May 1, 2013 at 9:00 AM, Anne van Kesteren  wrote:
> On Sun, Apr 28, 2013 at 12:56 PM, Brian Kardell  wrote:
>> We created a prollyfill for this about a year ago (called :-link-local
>> instead of :local-link for forward compatibility):
>>
>> http://hitchjs.wordpress.com/2012/05/18/content-based-css-link/
>
> Cool!
>
>
>> If you can specify the workings, we (public-nextweb community group) can rev
>> the prollyfill, help create tests, collect feedback, etc so that when it
>> comes time for implementation and rec there are few surprises.
>
> Did you get any feedback thus far about desired functionality,
> problems that are difficult to overcome, ..?
>
>
> --
> http://annevankesteren.nl/

We have not uncovered much on this one other than that the few people
who commented were confused by what it meant - but we didn't really
make a huge effort to push it out there... By comparison to some
others it isn't a very 'exciting' fill (our :has() for example had
lots of comment as did our mathematical attribute selectors) - but we
definitely can.  I'd like to open it up to these groups where/how you
think might be an effective means of collecting necessary data -
should we ask people to contribute comments to the list? set up a git
project where people can pull/create issues, register tests/track fork
suggestions, etc?  Most of our stuff for collecting information has
been admittedly all over the place (twitter, HN, reddit, blog
comments, etc), but this predates the nextweb group and larger
coordination, so I'm *very happy* if we can begin to change that.



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

Re: URL comparison

[Brian Kardell]

On Apr 25, 2013 1:39 PM, "Tab Atkins Jr."  wrote:
>
> On Thu, Apr 25, 2013 at 4:34 AM, Anne van Kesteren 
wrote:
> > Background reading: http://dev.w3.org/csswg/selectors/#local-pseudo
> > and http://url.spec.whatwg.org/
> >
> > :local-link() seems like a special case API for doing URL comparison
> > within the context of selectors. It seems like a great feature, but
> > I'd like it if we could agree on common comparison rules so that when
> > we eventually introduce the JavaScript equivalent they're not wildly
> > divergent.
>
> My plan is to lean *entirely* on your URL spec for all parsing,
> terminology, and equality notions.  The faster you can get these
> things written, the faster I can edit Selectors to depend on them. ^_^
>
> > Requests I've heard before I looked at :local-link():
> >
> > * Simple equality
> > * Ignore fragment
> > * Ignore fragment and query
> > * Compare query, but ignore order (e.g. ?x&y will be identical to
> > ?y&x, which is normally not the case)
> > * Origin equality (ignores username/password/path/query/fragment)
> > * Further normalization (browsers don't normalize as much as they
> > could during parsing, but maybe this should be an operation to modify
> > the URL object rather than a comparison option)
> >
> > :local-link() seems to ask for: Ignore fragment and query and only
> > look at a subset of path segments. However, :local-link() also ignores
> > port/scheme which is not typical. We try to keep everything
> > origin-scoped (ignoring username/password probably makes sense).
>
> Yes.
>
> > Furthermore, :local-link() ignores a final empty path segment, which
> > seems to mimic some popular server architectures (although those
> > ignore most empty path segments, not just the final), but does not
> > match URL architecture.
>
> Yeah, upon further discussion with you and Simon, I agree we shouldn't
> do this.  The big convincer for me was Simon pointing out that /foo
> and /foo/ have different behavior wrt relative links, and Anne
> pointing out that the URL spec still makes example.com and
> example.com/ identical.
>
> > For JavaScript I think the basic API will have to be something like:
> >
> > url.equals(url2, {query:"ignore-order"})
> > url.equals(url2, {query:"ignore-order", upto:"fragment"}) // ignores
fragment
> > url.equals(url2, {upto:"path"}) // compares everything before path,
> > including username/password
> > url.origin == url2.origin // ignores username/password
> > url.equals(url2, {pathSegments:2}) // implies ignoring query/fragment
> >
> > or some such. Better ideas more than welcome.
>
> Looks pretty reasonable.  Only problem I have is that your "upto" key
> implicitly orders the url components, when there are times I would
> want to ignore parts out-of-order.
>
> For example, sometimes the query is just used for incidental
> information, and changing it doesn't actually result in a "different
> page".  So, you'd like to ignore it when comparing, but pay attention
> to everything else.
>
> So, perhaps in addition to "upto", an "ignore" key that takes a string
> or array of strings naming components that should be ignored?
>
> This way, :local-link(n) would be equivalent to:
> linkurl.equals(docurl, {pathSegments:n, ignore:"userinfo"})
>
> :local-link would be equivalent to:
> linkurl.equals(docurl, {upto:"fragment"})  (Or {ignore:"fragment"})
>
> ~TJ
>

Anne/Tab,

We created a prollyfill for this about a year ago (called :-link-local
instead of :local-link for forward compatibility):

http://hitchjs.wordpress.com/2012/05/18/content-based-css-link/

If you can specify the workings, we (public-nextweb community group) can
rev the prollyfill, help create tests, collect feedback, etc so that when
it comes time for implementation and rec there are few surprises.

Re: [webcomponents]: Of weird script elements and Benadryl

[Brian Kardell]

Can Scott or Daniel or someone explain the challenge with creating a
"normal constructor" that has been mentioned a few times (Scott mentioned
has-a).  I get the feeling that several people are playing catch up on that
challenge and the implications that are causing worry.  Until people have
some shared understanding it is difficult to impossible to reach something
acceptable all around.  Hard to solve the unknown problems.

Re: [webcomponents]: Of weird script elements and Benadryl

[Brian Kardell]

On Apr 13, 2013 8:57 PM, "Daniel Buchner"  wrote:
>
> @Rick - if we generated a constructor that was in scope when the script
was executed, there is no need for rebinding 'this'. I'd gladly ditch the
rebinding in favor of sane, default, generated constructors.

I think we need someone to summarize where we are at this point :)

Is anyone  besides scott in favor of the

2) Invent a new element specifically for the purpose of defining prototypes

For the record, i am not.

Re: [webcomponents]: Re-imagining shadow root as Element

[Brian Kardell]

On Apr 10, 2013 1:24 PM, "Scott Miles"  wrote:
>
> So, what you quoted are thoughts I already deprecated mysefl in this
thread. :)
>
> If you read a bit further, see that  I realized that  is
really part of the 'outer html' of the node and not the inner html.
>
Yeah sorry, connectivity issue prevented me from seeing those until after i
sent i guess.

> >> I think that is actually a feature, not a detriment and easily
explainable.
>
> What is actually a feature? You mean that the shadow root is invisible to
innerHTML?
>


Yes.

> Yes, that's true. But without some special handling of Shadow DOM you get
into trouble when you start using innerHTML to serialize DOM into HTML and
transfer content from A to B. Or even from A back to itself.
>

I think Dimiti's implication iii is actually intuitive - that is what I am
saying... I do think that round-tripping via innerHTML would be lossy of
declarative markup used to create the instances inside the shadow... to get
that it feels like you'd need something else which I think he also
provided/mentioned.

Maybe I'm alone on this, but it's just sort of how I expected it to work
all along... Already, roundtripping can differ from the original source, If
you aren't careful this can bite you in the hind-quarters but it is
actually sensible.  Maybe I need to think about this a little deeper, but I
see nothing at this stage to make me think that the proposal and
implications are problematic.

Re: [webcomponents]: Re-imagining shadow root as Element

[Brian Kardell]

On Mon, Mar 18, 2013 at 5:05 PM, Scott Miles  wrote:
> I'm already on the record with A, but I have a question about 'lossiness'.
>
> With my web developer hat on, I wonder why I can't say:
>
> 
>   
> shadow stuff
>   
>
>   light stuff
>
> 
>
>
> and then have the value of #foo.innerHTML still be
>
>   
>  shadow stuff
>   
>
>   lightstuff
>
> I understand that for DOM, there is a wormhole there and the reality of what
> this means is new and frightening; but as a developer it seems to be
> perfectly fine as a mental model.
>
> We web devs like to grossly oversimplify things. :)
>
> Scott

I am also a Web developer and I find that proposal (showing in
innerHTML) feels really wrong/unintuitive to me... I think that is
actually a feature, not a detriment and easily explainable.

I am in a) camp

Re: [webcomponents]: de-duping in HTMLImports

[Brian Kardell]

On Tue, Apr 9, 2013 at 2:42 PM, Scott Miles  wrote:
> Duplicate fetching is not observable, but duplicate parsing and duplicate
> copies are observable.
>
> Preventing duplicate parsing and duplicate copies allows us to use 'imports'
> without a secondary packaging mechanism. For example, I can load 100
> components that each import 'base.html' without issue. Without this feature,
> we would need to manage these dependencies somehow; either manually, via
> some kind of build tool, or with a packaging system.
>
> If import de-duping is possible, then ideally there would also be an
> attribute to opt-out.
>
> Scott
>
>
> On Tue, Apr 9, 2013 at 11:08 AM, Dimitri Glazkov 
> wrote:
>>
>> The trick here is to figure out whether de-duping is observable by the
>> author (other than as a performance gain). If it's not, it's a
>> performance optimization by a user agent. If it is, it's a spec
>> feature.
>>
>> :DG<
>>
>> On Tue, Apr 9, 2013 at 10:53 AM, Scott Miles  wrote:
>> > When writing polyfills for HTMLImports/CustomElements, we included a
>> > de-duping mechanism, so that the same document/script/stylesheet is not
>> > (1)
>> > fetched twice from the network and (2) not parsed twice.
>> >
>> > But these features are not in specification, and are not trivial as
>> > design
>> > decisions.
>> >
>> > WDYT?
>> >
>> > Scott
>> >
>
>

For what it is worth, I think I might have opened a bug on this
already (long ago) - but it would have been mixed in with a larger
'how to load them'...

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

Re: [webcomponents]: Naming the Baby

[Brian Kardell]

On Mar 28, 2013 11:45 AM, "Dimitri Glazkov"  wrote:
>
> So. :
>
> rel type: "import"
>
> spec name:
>
> 1) "HTML Imports"
> 2) "Web Imports"
>
> :DG<
>

Makes sense to me!

Re: [webcomponents]: Naming the Baby

[Brian Kardell]

On Mar 27, 2013 2:27 PM, "Scott Miles"  wrote:
>
> The problem I'm trying to get at, is that while a 'custom element' has a
chance of meeting your 1-6 criterion, the thing on the other end of  has no such qualifications. As designed, the target
of this link is basically arbitrary HTML.
>
> This is why I'm struggling with .
>
> Scott
>
>
> On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro <
angelinafab...@gmail.com> wrote:
>>
>> Just going to drop this in here for discussion. Let's try and get at
what a just a component 'is':
>>
>> A gold-standard component:
>>
>> 1. Should do one thing well
>> 2. Should contain all the necessary code to do that one thing (HTML, JS,
CSS)
>> 3. Should be modular (and thus reusable)
>> 4. Should be encapsulated
>> 5. (Bonus) Should be as small as it can be
>>
>> I think it follows, then, that a 'web component' is software that fits
all of these criteria, but for explicit use in the browser to build web
applications. The tools provided - shadow DOM, custom elements etc. give
developers tools to create web components. In the case of:
>>
>> 
>>
>> I would (as mentioned before) call this a 'component include' as I think
this description is pretty apt.
>>
>> It is true that widgets and components are synonymous, but that has been
that way for a couple of years now at least already. Widgets, components,
modules - they're all interchangeable depending on who you talk to. We've
stuck with 'components' to describe things so far. Let's not worry about
the synonyms. So far, the developers I've introduced to this subject
understood implicitly that they could build widgets with this stuff, all
the while I used the term 'components'.
>>
>> Cheers,
>>
>> - A
>>
>> On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles  wrote:
>>>
>>> Forgive me if I'm perseverating, but do you imagine 'component' that is
included to be generic HTML content, and maybe some scripts or some custom
elements?
>>>
>>> I'm curious what is it you envision when you say 'component', to test
my previous assertion about this word.
>>>
>>> Scott
>>>
>>>
>>> On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro <
angelinafab...@gmail.com> wrote:

 'Component Include'

 'Component Include' describes what the markup is doing, and I like
that a lot. The syntax is similar to including a stylesheet or a script and
so this name should be evocative enough for even a novice to understand
what is implied by it.

 - Angelina


 On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles 
wrote:
>
> Fwiw, my main concern is that for my team and for lots of other
people I communicate with, 'component' is basically synonymous with 'custom
element'. In that context, 'component' referring to
chunk-of-web-resources-loaded-via-link is problematic, even if it's not
wrong, per se.
>
> We never complained about this before because Dimitri always wrote
the examples as  (note the plural). When it was
changed to  was when the rain began.
>
> Scott
>
>
> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
wrote:
>>
>> I like the idea of "package" seems all encompassing which captures
the requirements nicely. That or perhaps "resource", but then resource
seems singular.
>>
>> Or perhaps "component-package" so it is obvious that it's tied to
web components?
>>
>> -Ryan
>>
>>
>> On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov 
wrote:
>>>
>>> Hello folks!
>>>
>>> It seems that we've had a bit of informal feedback on the "Web
>>> Components" as the name for the  spec (cc'd some
>>> of the "feedbackers").
>>>
>>> So... these malcontents are suggesting that "Web Components" is
more a
>>> of a general name for all the cool things we're inventing, and >> rel=component> should be called something more specific, having to
do
>>> with enabling modularity and facilitating component dependency
>>> management that it actually does.
>>>
>>> I recognize the problem, but I don't have a good name. And I want to
>>> keep moving forward. So let's come up with a good one soon? As
>>> outlined in
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html
>>>
>>> Rules:
>>>
>>> 1) must reflect the intent and convey the meaning.
>>> 2) link type and name of the spec must match.
>>> 3) no biting.
>>>
>>> :DG<
>>
>>
>

>>>
>>
>

This is why I suggested prototype.. It might be an arbitrary doc, but it's
intent really is to serve as kinda a way to get things you intend to insert
into your page may or not be components to the definition... I saw no
uptake, but that was the rationale: it's hard to not use widget or
component.

Re: [webcomponents]: Naming the Baby

[Brian Kardell]

On Mar 25, 2013 3:03 PM, "Dimitri Glazkov"  wrote:
>
> Hello folks!
>
> It seems that we've had a bit of informal feedback on the "Web
> Components" as the name for the  spec (cc'd some
> of the "feedbackers").
>
> So... these malcontents are suggesting that "Web Components" is more a
> of a general name for all the cool things we're inventing, and  rel=component> should be called something more specific, having to do
> with enabling modularity and facilitating component dependency
> management that it actually does.
>
> I recognize the problem, but I don't have a good name. And I want to
> keep moving forward. So let's come up with a good one soon? As
> outlined in
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html
>
> Rules:
>
> 1) must reflect the intent and convey the meaning.
> 2) link type and name of the spec must match.
> 3) no biting.
>
> :DG<

I'm sure this is flawed and i will regret sharing it without more
consideration after it popped into my head - but what about something like
"prototype"?  Does that need explanation as to where i pulled that from or
is it obvious?

Re: [webcomponents]: First stab at the Web Components spec

[Brian Kardell]

On Mar 18, 2013 10:48 AM, "Tab Atkins Jr."  wrote:
>
> On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost  wrote:
> > Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit :
> >> Here's a first rough draft of the Web Components spec:
> >>
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html
> >
> > Cool.
> >
> > I see
> >
> > 
> >
> > Do you plan to allow the HTTP counterpart?
> >
> > Link: ; rel=component
>
> Does that need to be "allowed"?  I thought the Link header was just
> equivalent, in general, to specify a  in your head.
>
> ~TJ
>

Just bringing this up on list as it has come up in conversations offlist:
while not currently valid.for htmk, link for Web components will work in
the body too? #justcheckin

Re: [webcomponents]: What callbacks do custom elements need?

[Brian Kardell]

On Mar 11, 2013 9:03 PM, "Boris Zbarsky"  wrote:
>
> On 3/11/13 8:59 PM, Brian Kardell wrote:
>>
>> Is it very difficult to provide "here is an attribute I'm watching + a
>> callback"?
>
>
> It's not super-difficult but it adds more complication to
already-complicated code
>
> One big question is whether in practice the attribute that will be
changing is one that the consumer cares about or not.  If it's the former,
it makes somewhat more sense to put the checking of which attribute in the
consumer.
>
> -Boris

Daniel can confirm but in all of the stuff i have seen and played with so
far it is...you want a changing a component attribute to have some effect.
Internally you would use mutation observers i think.

Re: [webcomponents]: What callbacks do custom elements need?

[Brian Kardell]

Sorry I clicked send accidentally there... I meant to mention that I think
this is sort of the intent of attributeFilter in mutation observers


On Mon, Mar 11, 2013 at 5:59 PM, Brian Kardell  wrote:

> Is it very difficult to provide "here is an attribute I'm watching + a
> callback"?  Most things require us to write switches and things and receive
> overly broad notifications which aren't great for performance or for code
> legibility IMO.
>
> Just curious.
>
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>



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

Re: [webcomponents]: What callbacks do custom elements need?

[Brian Kardell]

Is it very difficult to provide "here is an attribute I'm watching + a
callback"?  Most things require us to write switches and things and receive
overly broad notifications which aren't great for performance or for code
legibility IMO.

Just curious.


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

Re: [webcomponents]: What callbacks do custom elements need?

[Brian Kardell]

On Mon, Mar 11, 2013 at 1:16 PM, Boris Zbarsky  wrote:

> On 3/11/13 3:44 PM, Daniel Buchner wrote:
>
>> Just to be clear, these are callbacks (right?), meaning synchronous
>> executions on one specific node. That is a far cry from the old issues
>> with mutation events and nightmarish bubbling scenarios.
>>
>
> Where does bubbling come in?
>
> The issue with _synchronous_ (truly synchronous, as opposed to end of
> microtask or whatnot) callbacks is that they are required to fire in the
> middle of DOM mutation while the DOM is in an inconsistent state of some
> sort.  This has nothing to do with bubbling and everything to do with what
> happens when you append a node somewhere while it already has a parent and
> it has a removed callback that totally rearranges the DOM in the middle of
> your append.


So does it actually need to be sync at that leve?  I'm not sure why it does
really.  Can someone explain just for my own clarity?

-Brian

Re: Feedback and questions on shadow DOM and web components

[Brian Kardell]

Brian Kardell :: @bkardell :: hitchjs.com
On Nov 13, 2012 9:34 AM, "Angelina Fabbro"  wrote:
>
> Hello public-webapps,
>
> I'm Angelina, and I've been very interested in shadow DOM and web
components for some time now. So much so that I've tried to teach people
about them several times. There's a video from JSConfEU floating around on
Youtube if you're interested . I think I managed to get the important parts
right despite my nerves. I've given this sort of talk four times now, and
as a result I've collected some feedback and questions from the developers
I've talked to.
>
> 1. It looks like from the spec and the code in Glazkov's polyfill that if
I add and remove the 'is' attribute, the shadow tree should apply/unapply
itself to the host element.

Two things: 1. Added in markup or dynamically?  The draft says it can't be
added dynamically just in case...  2.  The draft itself is a little unclear
on "is".  Early in the text, the reference was changed to say that these
will be custom tags, in other words  instead of .  Mozilla's x-tags is currently operating under that assumption
as well.

> I've not found this to be the case. See my examples for 2. below - I
tried applying and unapplying the 'is' attribute to remix the unordered
list using a template without success.

>
>
>