Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Fri, Jan 9, 2015 at 8:08 AM, Dimitri Glazkov dglaz...@google.com wrote:
 Here's an attempt from 2012. This approach doesn't work (the trivial
 plumbing mentioned in the doc is actually highly non-trivial), but maybe it
 will give some insights to find the right a proper solution:

 https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing

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

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

[oof, somehow your latest response flattened all of the quotes]

On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 ? I didn't mention DOM APIs.  I'm referring back to the example you're
 replying to - if you use a bar element inside your foo component,
 and you know that bar has isolation styles, you have to specifically
 call that out inside your foo styling so that it (a) is shielded
 from your foo styles, and (b) is able to pick up the global definition
 for bar styles.  This is relatively clumsy.  Some of the other
 solutions attach the I want to be isolated information to the
 element itself more directly, so you don't have to worry about what
 you put inside of yourself.

 This is no more clumsy than defining an insertion points in shadow DOM.  Or
 am I misunderstanding you?

Yeah.  In Shadow DOM, you can just *use* the bar element, without
having to think about it.  If it happens to also use shadows to
isolate its contents, that's irrelevant to you; you dont' have to make
a single change to your foo component in order to recognize that.
That's nice composition, which isn't *strictly* necessary in any
solution, but it's a really good thing.

 I listed a number of APIs in the text you're responding to, all of
 which may or may not want to pay attention to style isolation,
 depending on the use-case.  I'm not saying you necessarily need DOM
 isolation for any given use-case.  I'm saying that there are a lot of
 APIs that query or walk the DOM, and whether they should pay attention
 to a style isolation boundary is a question without clear answers.

 I don't understand what you mean here.  As far as I know, there are only two
 sensible options here:

 Style isolation implies DOM subtree isolation in all DOM APIs
 Style isolation doesn't affect DOM APIs at all

 Shadow DOM does 1.  I'm suggesting that we need a mechanism to do 2.  It's
 not terrible if we introduced @isolate to do 1 and also provided shadow DOM
 to do 1.  In that world, shadow DOM is a syntax sugar around @isolate in the
 CSS land with DOM API implications.

I mean, those are two possible options.  They're not the only ones.
For example, you could say that all selectors pay attention to the
isolation boundary, so qSA is affected.  That's *a* consistent answer,
and could be very reasonable - people often use qSA to do
styling-related things, and having it respect the style boundaries
makes sense there.

I'm saying there are multiple places you can draw the line.  I think
there's a nice defensible spot at the point you end up with when you
do DOM isolation - everything that cares about the DOM tree (which
includes CSS selectors, defined in terms of the DOM tree) gets locked
out by default.  Anywhere else has arguments for it, but I don't think
any of them are particularly more compelling than any other.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Let's assume we did it, though.  We'd have to have some mechanism for
 defining an isolation boundary, and denoting whether rules were
 inside or outside the boundary.  This sounds like an at-rule,
 like:

 @isolate .example {
 h1 { ... }
 div { ... }
 }

 Now, a problem here is that you have a conflict between nesting
 isolated things and specifying isolation.  Say you have foo and
 bar elements, both of which need to be isolated. You'd think you
 could just write:

 @isolate foo {
 ...
 }
 @isolate bar {
 ...
 }

 But this won't work! If you have markup like
 foobar.../bar/foo, the bar there is inside the foo's
 isolation boundary, so the @isolate rule can't find it.  You'd need to
 *also* nest the @isolate bar rule (and all its styling rules) within
 the foo one, and vice versa.  The effect of this on *three* mutually
 isolated components is, obviously, terrible; let's not even mention
 trying to use multiple modules together that weren't explicitly
 designed together.

 Alternately, say that it does work - the @isolate selector pierces
 through isolation boundaries.  Then you're still screwed, because if
 the outer page wants to isolate .example blocks, but within your
 component you use .example normally, without any isolation, whoops!
 Suddenly your .example blocks are isolated, too, and getting weird
 styles applied to them, while your own styles break since they can't
 cross the unexpected boundary.

 Another alternative.  We can add a host language dependent mechanism such 
 as an element or an attribute to end the current isolation, just like 
 insertion points in a shadow DOM would.
 Better yet, we can provide this mechanism in CSS. e.g.

 @isolate foo integrates(bar) {
  ...
 }

 @isolate bar {
  ...
 }

 (I'm not proposing this exact syntax. We can certainly do better.)

 Yeah, something like that would work, but it also means you need to
 account for all the things that might want to be isolated in your
 component.  That's relatively clumsy.

 Examples?  Are you talking about DOM APIs such as querySelectorAll and alike? 
  Then, please refer to my other reply [1] in which I listed use cases that 
 involve no author scripts.

? I didn't mention DOM APIs.  I'm referring back to the example you're
replying to - if you use a bar element inside your foo component,
and you know that bar has isolation styles, you have to specifically
call that out inside your foo styling so that it (a) is shielded
from your foo styles, and (b) is able to pick up the global definition
for bar styles.  This is relatively clumsy.  Some of the other
solutions attach the I want to be isolated information to the
element itself more directly, so you don't have to worry about what
you put inside of yourself.

 This last one, though, is pretty much exactly Custom Elements, just
 with the children staying in the light tree rather than being moved
 into a shadow tree.  But keeping them in the light tree has
 complications; it means that everything in the platform needs to be
 made aware of the isolation boundary.  Should qSA respect the
 isolation boundaries or not?  Depends on what you're using it for.
 What about things that aren't CSS at all, like getElementsByTagName()?
 That's equivalent to a qSA with the same argument, but it's not a
 selector, per se.  Manual tree-walking would also need to be made
 aware of this, or else you might accidentally descend into something
 that wants isolation.  Shadow DOM at least gives an answer to all of
 these, by putting the elements in a separate tree.  You don't need to
 think of every one individually, or deal with inconsistent design when
 someone forgets to spec their new tree-searching thing to respect the
 boundary.

 Let's not conflate style isolation with isolation of DOM subtrees.  They're 
 two distinct features.  Even though I do agree it might be desirable to 
 have both in many important use cases, there are use cases in which we 
 don't need subtree isolations.

 I'm not trying to, I'm pointing out that style isolation, as a
 concept, seamlessly blends into DOM isolation as you move across API 
 surfaces.

 I don't see any connection between the two.  Many of the use cases I listed 
 [1] require us to have DOM isolations.

I listed a number of APIs in the text you're responding to, all of
which may or may not want to pay attention to style isolation,
depending on the use-case.  I'm not saying you necessarily need DOM
isolation for any given use-case.  I'm saying that there are a lot of
APIs that query or walk the DOM, and whether they should pay attention
to a style isolation boundary is a question without clear answers.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

[ryosuke, your mail client keeps producing flattened replies. maybe
send as plain-text, not HTML?]

On Mon, Jan 12, 2015 at 5:23 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 ? I didn't mention DOM APIs.  I'm referring back to the example you're
 replying to - if you use a bar element inside your foo component,
 and you know that bar has isolation styles, you have to specifically
 call that out inside your foo styling so that it (a) is shielded
 from your foo styles, and (b) is able to pick up the global definition
 for bar styles.  This is relatively clumsy.  Some of the other
 solutions attach the I want to be isolated information to the
 element itself more directly, so you don't have to worry about what
 you put inside of yourself.

 This is no more clumsy than defining an insertion points in shadow DOM.  Or
 am I misunderstanding you?

 Yeah.  In Shadow DOM, you can just *use* the bar element, without
 having to think about it.

 I don't know what you mean by one doesn't have to think about it.  The style
 applied on bar won't propagate into the shadow DOM by default [1] unless
 we use /deep/ or  [2]

The style defined for bar *in bar's setup code* (that is, in a
style contained inside bar's shadow tree) works automatically
without you having to care about what bar is doing.  bar is like a
replaced element - it has its own rendering, and you can generally
just leave it alone to do its thing.

In the previous examples, we weren't talking about defining styling
for bars that are specifically inside of foos, just how to style
bar generically, regardless of its context.  Current shadow DOM
makes that easy to do without requiring the different components to
know about each other in any way; the declarative CSS mechanisms we
were previously discussing did not.

 I mean, those are two possible options.  They're not the only ones.
 For example, you could say that all selectors pay attention to the
 isolation boundary, so qSA is affected.  That's *a* consistent answer,
 and could be very reasonable - people often use qSA to do
 styling-related things, and having it respect the style boundaries
 makes sense there.

 I'm saying there are multiple places you can draw the line.  I think
 there's a nice defensible spot at the point you end up with when you
 do DOM isolation - everything that cares about the DOM tree (which
 includes CSS selectors, defined in terms of the DOM tree) gets locked
 out by default.  Anywhere else has arguments for it, but I don't think
 any of them are particularly more compelling than any other.

 What are other sensible alternatives?  I agree there are other options but
 they aren't sensible as far as I'm concerned.

 [1] http://jsfiddle.net/seyL1vqn/
 [2] http://jsfiddle.net/seyL1vqn/1/

I listed several in the text you're responding to, and previous replies.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 [ryosuke, your mail client keeps producing flattened replies. maybe
 send as plain-text, not HTML?]

 Weird.  I'm not seeing that at all on my end.

It's sending HTML-quoted stuff, which doesn't survive the flattening
to plain-text that I and a lot of others do.  Plain-text is more
interoperable.

 The style defined for bar *in bar's setup code* (that is, in a
 style contained inside bar's shadow tree) works automatically
 without you having to care about what bar is doing.  bar is like a
 replaced element - it has its own rendering, and you can generally
 just leave it alone to do its thing.

 If that's the behavior we want, then we should simply make @isolate pierce 
 through isolates.  You previously mentioned that:

 On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Alternately, say that it does work - the @isolate selector pierces
 through isolation boundaries.  Then you're still screwed, because if
 the outer page wants to isolate .example blocks, but within your
 component you use .example normally, without any isolation, whoops!
 Suddenly your .example blocks are isolated, too, and getting weird
 styles applied to them, while your own styles break since they can't
 cross the unexpected boundary.

 But this same problem seems to exist in shadow DOM as well.  We can't have a 
 bar inside a foo behave differently from ones outside foo since all bar 
 elements share the same implementation.  I agree

Yes!  But pay attention to precisely what I said: it's problematic to,
for example, have a command to isolate all class=example elements
pierce through isolation boundaries, because classes aren't expected
to be unique in a page between components - it's very likely that
you'll accidentally hit elements that aren't supposed to be isolated.
It's okay to have *element name* isolations pierce, though, because we
expect all elements with a given tagname to be the same kind of thing
(and Web Components in general is built on this assumption; we don't
scope the tagnames in any way).

But then we're not actually providing selectors to the isolate
mechanism, we're just providing tagnames, and having that affect the
global registry of tagnames.  That's fine, it's just a different type
of solution, with different contours, and it's much closer to normal
web components stuff.  (And thus it makes more sense to stick as close
to web components as reasonable, to reduce the number of
slightly-different concepts authors have to think about.)

~TJ

Re: Custom element design with ES6 classes and Element constructors

[Tab Atkins Jr.]

On Mon, Jan 12, 2015 at 5:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola d...@domenic.me wrote:
 However, I don't understand how to make it work for upgraded elements at all

 Yes, upgrading is the problem. There's two strategies as far as I can
 tell to maintain a sane class design:

 1) There is no upgrading. We synchronously invoke the correct
 constructor. I've been trying to figure out the drawbacks, but I can't
 find the set of mutation events problems that relates to this. One
 obvious drawback is needing to have all the code in place so you might
 need a way to delay the parser (return of synchronous script
 loading).

That's the issue - you have to have all custom element definitions
loaded before any of your app is allowed to load, or else you'll have
confusing errors where your elements just don't work, or work in racy
conditions because you're racing an async script download against the
download+parse of the rest of the document.

 2) As you indicate, upgrading becomes replacing. This used to be the
 old model and got eventually killed through
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21063 though there's no
 clear summary as to why that happened. Issues seem to be: mutation
 observer spam, dangling references, attributes, event listeners.

Yeah, as you say, this is also likely to be racy and bug-prone -
sometimes your events stick around (because the script that set them
ran after the script that initialized the element) and sometimes they
don't (because the race went the other way).  Even in the lack of
races, more non-obvious ordering constraints are confusing to authors.

 Forever prototype munging seems really broken too so we should really
 revisit these two approaches to custom elements I think.

Proto munging isn't even that big of a deal. It's the back-end stuff
that's kinda-proto but doesn't munge that's the problem.  This is
potentially fixable if we can migrate more elements out into JS space.

~TJ

Re: Shadow tree style isolation primitive

[Tab Atkins Jr.]

On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay o...@pettay.fi wrote:
 Why should even !important work if the component wants to use its own
 colors?

Because that's how !important usually works.  If the author has
progressed to the point of doing !important, we should assume that
they know what they're doing and let it work.  At the end of the day,
it should be possible for the outer page to have some way of styling
any part of a non-sealed (a la inputs, etc) shadow DOM.  Anyone
claiming this isn't necessary should be sentenced to a year of doing
web dev with jQuery components and hostile clients.

~TJ

Re: Are web components *seriously* not namespaced?

[Tab Atkins Jr.]

On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@gmail.com wrote:
 So in other words it *is* a case of it's good enough. Web components are
 quite possibly the future of the web, and yet we're implementing them to be
 good enough in 90% of use cases?

 jQuery is JavaScript which means that it's different for various reasons:

 1. It's less important to keep the names short.
 2. It's possible to rename a plug-in if there is a conflict (e.g. @
 http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name)
 3. It's a library, not something built into the browser, which means that if
 jQuery decides to add some form of namespacing, it doesn't require a major
 specification and implementation by 5+ major browsers, etc.

Web Components are also JS.  Any renaming you do in JS, you can do
just as easily in HTML.

 Complicating things further simply isn't all that necessary.
 Complicating it for the developer, or the implementers? I can't speak for
 the latter, but for developers, this would be an *optional* feature. If you
 don't have conflicts you don't *have* to alter an element's NS prefix, but
 specifying the prefix in your HTML would provide rich IDE functionality, so
 I don't see why anyone would *not* want to do this.

Again, namespaces are nothing more than an indirection mechanism for
prefixes, so you can write a long and more-likely-unique prefix as a
shorter prefix that you know is unique for your page.  No
functionality is enabled by namespaces that can't be done without them
just as easily but with a little more verbosity.

 It's something that can be added organically as necessary.
 Anne has already made a point about this, but also consider the fact that
 without real namespacing, we're forced to name based on *potential*
 conflicts. For example, in the ms- case, ms- may either already exist, or
 *potentially* exist and be useful, so I name my element mks- instead.
 Therefore I'm not able to give something the name that I want it to have,
 for fear of future conflicts.

Anne pointed out that XML Namespaces screwed this up, not that it's
not easy to get right.

You don't need to fear future conflicts.  Googling for a name is often
sufficient.  You can change later if there is a conflict.

 Even just being able to optionally shorten a custom element's NS prefix can
 be useful. For example, if a vendor uses excalibur-grid, we can just
 change that to x-grid and things will be easier to type, cleaner, etc.

 Regarding XML, I never even mentioned XML in my initial post, so I'm not
 sure what all the fuss is about. This can be implemented in a way that
 supports both HTML *and* XHTML/XML, yet doesn't look at all like XML
 namespacing. The only important part is the use of URIs, I can see no better
 way of providing both a unique namespace, as well as an endpoint for
 gathering human-  machine-readable data about a set of custom elements. Is
 there something inherently wrong with this? Or is this just about people
 being too lazy to type a closing tag, because that can remain optional.

Most people who mention namespaces on the web are referring to XML
Namespaces, so I assumed you were as well.  Your suggestion is shaped
exactly like XML Namespaces, with the use of urls as namespace, etc.

 They [XML namespaces] have a number of terrible affordances
 +
 Most of them don't commit the same mistakes that XML namespaces did
 Such as?

A few are:

* URLs are not a good fit for namespaces. Humans make a number of
assumptions about how urls can be changed (capitalization, trailing /,
http vs https, www or not, etc) which are often true for real urls due
to nice server software, but are not true for urls, which are opaque
strings.
* There's no consistency in the URL structure used: some namespaces
end in a word, some in a slash, some in a hash, etc.
* You can't actually fetch namespace urls.  Again, they're opaque
strings, not urls, so there's no guarantee or expectation that there's
anything useful on the other side, or that what is on the other side
is parseable in any way.  As a given XML namespace becomes more
popular, fetching the namespace url constitutes a DDOS attack; the
W3C, for example, has to employ sophisticated caching to prevent
namespace url requests from taking down their website.
* URLs contain a bunch of extra typing baggage that don't serve to
uniquify anything, just make it longer to type.  The http://; prefix,
for example, is identical for all namespaces (and if it's not, it's
one more hurdle for authors to run into).  Using a string with a
higher information content is better for authors.
* Domain names don't mean much. For example, Dublin Core's namespace
starts with http://purl.org/;, which is effectively meaningless.
* Similarly, path components often exist which are worthless and just
lengthen the namespace for no uniquifying gain, such as the SVG
namespace http://www.w3.org/2000/svg which contains /2000/ for some
historical reason (it was minted 

Re: Standardising canvas-driven background images

[Tab Atkins Jr.]

On Fri, Feb 20, 2015 at 1:50 PM, Matthew Robb matthewwr...@gmail.com wrote:
 On Fri, Feb 20, 2015 at 2:25 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
 Images level 4

 If/when that spec reappears it would be great if you could reply to this
 thread with a link or something... Thanks!

Here we are: http://dev.w3.org/csswg/css-images-4/#element-notation

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

[Sorry for the reply-chain breaking; Gmail is being super weird about
your message in particular, and won't let me reply directly to it.
Some bug.]

Karl Dubost said:
 The intersection seems to be:
 ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 
 'iframe', 'audio', 'font']

Whoops, sorry, forgot about title.  We can resolve that conflict in
favor of SVG; putting an html title into a template is, I suspect,
exceedingly rare.

track/canvas/source/video/iframe/audio are all being removed as the
SVGWG switches to allowing HTML elements natively in SVG.

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking jo...@sicking.cc wrote:
 Unless the SVG WG is willing to drop support for
 script![CDATA[...]]/script. But that seems like it'd break a lot
 of content.

Like, on the same line? Because I recall that sort of thing showing up
in old HTML tutorials, with the CDATA parts on their own lines.

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote:
 What are your thoughts on this idea?

 I think it would be more natural (HTML-parser-wise) if we
 special-cased SVG elements, similar to how e.g. table elements are
 special-cased today. A lot of template-parsing logic is set up so
 that things work without special effort.

Absolutely.  Forcing authors to write, or even *think* about,
namespaces in HTML is a complete usability failure, and utterly
unnecessary.  The only conflicts in the namespaces are font
(deprecated in SVG2), script and style (harmonizing with HTML so
there's no difference), and a (attempting to harmonize API surface).

If you just looked at the root element, skipping through as, you
could do the same magical mode selection we currently do for tr/etc.

Ideally we could do this by just pulling SVG into the HTML namespace,
which the SVGWG is comfortable with, but no implementors have felt
like doing it yet. :/

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

On Fri, Mar 13, 2015 at 1:27 PM, Benjamin Lesh bl...@netflix.com wrote:
 I agree completely, Tab, but it's actually too late to stop forcing authors
 to think about namespaces, the fact I currently have to think about it is
 the source of this suggestion.

You have to think about it today *because we've failed to do things
correctly*.  That doesn't mean we can't fix it so you can continue to
blithely ignore namespaces, like you can otherwise do for everything
except the createElement*() functions.

 The merging of namespaces is the ideal solution, no doubt, but it's probably
 not a realistic solution in the short or even medium term. It's almost the
 equivalent of punting.  SVG and HTML differ too drastically to just combine
 them overnight, I suspect. Different types stored in properties, different
 APIs, etc.

On the API level this is completely unproblematic.  SVGElement is
already a subclass of Element; the namespace really isn't a big deal.

The compat issue is just with libraries that branch on the namespace
for some reason, and that might be what kills this.

Importantly, though, we don't have to merge namespaces to make
template work correctly.  SVG already resolved that template
inside of SVG *should* be the HTMLTemplateElement, not a brand new
svg:template element that acts identically.  The template element
itself already has special parsing rules that cause it to start in
particular parser modes, to correctly handle things like
templatetrtdfoo/td/tr/template; giving it some more rules
to correctly handle templatecircle/circle/template isn't
difficult or unrealistic.  With that, users of template can just
ignore namespaces entirely, except for the corner case of
templateatext/a/template, which'll get interpreted as the
html:a element rather than svg:a.  Namespace unification closes
this final gap; it's not needed for the rest.

 It would be far easier/quicker to add an attribute and deprecate it later
 than get the namespaces merged. At the very least, it would immediately
 provide authors something they could polyfill to solve this issue.

Deprecation doesn't remove things; every thing we add, we should
assume is permanent.

Immediately is a funny term to use when discussing standards.
Adding an attribute and having it be useful cross-browser isn't any
faster than adding to the special cases for SVG-in-template.

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote:
 What are your thoughts on this idea?

 I think it would be more natural (HTML-parser-wise) if we
 special-cased SVG elements, similar to how e.g. table elements are
 special-cased today. A lot of template-parsing logic is set up so
 that things work without special effort.

 Absolutely.  Forcing authors to write, or even *think* about,
 namespaces in HTML is a complete usability failure, and utterly
 unnecessary.  The only conflicts in the namespaces are font
 (deprecated in SVG2), script and style (harmonizing with HTML so
 there's no difference), and a (attempting to harmonize API surface).

 Note that the contents of a HTML script parses vastly different from
 an SVG script. I don't recall if the same is true for style.

 So the parser sadly still needs to be able to tell an SVG script
 from a HTML one.

 I proposed aligning these so that parsing would be the same, but there
 was more opposition than interest back then.

That's back then.  The SVGWG is more interested in pursuing
convergence now, per our last few F2Fs.

~TJ

Re: Standardising canvas-driven background images

[Tab Atkins Jr.]

On Fri, Feb 20, 2015 at 7:51 AM, Ashley Gullen ash...@scirra.com wrote:
 Forgive me if I've missed past discussion on this feature but I need it so
 I'm wondering what the status of it is. (Ref:
 https://www.webkit.org/blog/176/css-canvas-drawing/ and
 http://updates.html5rocks.com/2012/12/Canvas-driven-background-images, also
 known as -webkit-canvas() or -moz-element())

 The use case I have for it is this: we are building a large web app that
 could end up dealing with thousands of dynamically generated icons since it
 deals with large user-generated projects. The most efficient way to deal
 with this many small images is to basically sprite sheet them on to a canvas
 2d context. For example a 512x512 canvas would have room for a grid of 256
 different 32x32 icons. (These are drawn scaled down from user-generated
 content, so they are not known at the time the app loads and so a normal
 image cannot be used.) To display an icon, a 32x32 div sets its background
 image to the canvas at an offset, like a normal CSS sprite sheet but with a
 canvas.

 -webkit-canvas solves this, but I immediately ran in to bugs (in Chrome
 updating the canvas does not always redraw the background image), and as far
 as I can tell it has an uncertain future so I'm wary of depending on it. The
 workarounds are:
 - toDataURL() - synchronous so will jank the main thread, data URL inflation
 (+30% size), general insanity of dumping a huge string in to CSS properties
 - toBlob() - asynchronous which raises complexity problems (needs a way of
 firing events to all dependent icons to update them; updating them requires
 DOM/style changes; needs to handle awkward cases like the canvas changing
 while toBlob() is processing; needs to be carefully scheduled to avoid
 thrashing toBlob() if changes being made regularly e.g. as network requests
 complete). I also assume this uses more memory, since it effectively
 requires creating a separate image the same size which is stored in addition
 to the canvas.

 In comparison being able to put a canvas in a background images solves this
 elegantly: there is no need to convert the canvas or update the DOM as it
 changes, and it seems the memory overhead would be lower. It also opens up
 other use cases such as animated backgrounds.

 I see there may be security concerns around -moz-element() since it can use
 any DOM content. This does not appear to be necessary or even useful (what
 use cases is arbitrary DOM content for?). If video is desirable, then video
 can already be rendered to canvases, so -webkit-canvas still covers that.

 Therefore I would like to propose standardising this feature based off the
 -webkit-canvas() implementation.

The correct standardized approach is the element() function, defined
in Images level 4 (I'd link you, but I think I accidentally killed the
spec; wait a bit).  -moz-element() is a pre-spec implementation of
this that mostly matches the spec.

There aren't any security bugs; this just lets you paint a part of the
tree twice.  Anything you can do to attack the image generated by
element(), you can do to attack the DOM that element() is pointing to.

~TJ

Re: template namespace attribute proposal

[Tab Atkins Jr.]

On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Karl Dubost said:
 The intersection seems to be:
 ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 
 'iframe', 'audio', 'font']

 Whoops, sorry, forgot about title.  We can resolve that conflict in
 favor of SVG; putting an html title into a template is, I suspect,
 exceedingly rare.

 That may be true but the added complexity of title inside a template 
 element being special (i.e. it’s treated as SVG instead of HTML) may not be 
 worth the effort.  HTML parser is already complex enough that using a simple 
 rule of always falling back to HTML if element names are ambiguous may result 
 in a better overall developer ergonomics.

Possibly, dunno.  I could go either way.  Consistently resolving
ambiguity in one direction could be simpler, but so could resolving in
favor of the massively-more-likely one.  Spec/impl complexity isn't
really of concern here; impls would need an explicit list of
elements/namespaces anyway. The spec could possible get away with a
blanket statement, but that opens up the possibility of ambiguity,
like image (which should clearly be SVG, despite the parser turning
it into img for you).

~TJ

Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

[Tab Atkins Jr.]

On Tue, Jan 13, 2015 at 2:05 PM, Mats Palmgren m...@mozilla.com wrote:
 On 01/12/2015 07:59 PM, Ben Peters wrote:

 Multiple selection is an important feature in the future.


 Indeed, there are many important use cases for it.

 Here are some use cases that are implemented using multi-range selections
 in Gecko today:
  * visual selection of bidirectional text
  * selecting table columns
  * selecting multiple fragments of arbitrary content (just hold CTRL)
  * selection with disjoint unselected islands due to CSS user-select:none
  * mapping spell-checking errors
  * highlighting matched words for Find in Page
 etc

If we ever want to make selection of text in pages using Flexbox or
Grid make sense, we'll need multiple selections, too.  The assumption
that you can accurately capture a visually-contiguous block of content
with two DOM endpoints is rapidly becoming untenable.

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

This is literally reinventing Selectors at this point.  The solution
to we don't think it's worth implementing *all* of Selectors is to
define a subset of supported Selectors, not to define a brand new
mechanism that's equivalent to selectors but with a new syntax.

On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani
justinfagn...@google.com wrote:
 Another technique I've seen used is compound selectors, which could be used
 to migrate from one selector to another while preserving backwards
 compatibility, or to provide some nice default distributions that are also
 accessible via a class or attribute (ie, select=header, .header).

 Could slots have multiple names to support something like this?

 On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com
 wrote:



 On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com
  wrote:
 
  I do want the ability to redirect distributed nodes into a holes in the
  base template, so that part is welcome to me. However, my first reaction 
  to
  the slot idea is that forcing users to add the content-slot attribute on
  children significantly impairs the DOM API surface area of custom 
  elements.
 
  For the single-level distribution case, how is this different from
  content select=[content-slot=name] except that content select can
  distribute based on features of the children that might already exist, 
  like
  tag names or an attribute?

 At the conceptual level, they're equivalent.  However, we didn't find the
 extra flexibility of using CSS selectors compelling as we mentioned in our
 proposal [1].


 I personally would like to see more power, especially positional
 selectors. Some components would be better off selecting their first child,
 rather than requiring a class.


 [1] See points 3 and 4 in
 https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec


 Point 4 is interesting, because unless I'm missing something (which could
 be!) it's incorrect. You can create selectors with :not() that exclude the
 content selectors that come after in document order. I would rewrite the
 example as:

 template
   content select=.header/content
   content select=:not(.footer)/content
   content select=.footer/content
 /template

 Cheers,
   Justin




 - R. Niwa

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots, 
 element-named slots, and everything-else-slots, we're now in a weird place 
 where we've reinvented a micro-language with some, but not all, of the power 
 of CSS selectors. Is adding a new micro-language to the web platform worth 
 helping implementers avoid the complexity of implementing CSS selector 
 matching in this context?

 I don't think mapping an attribute value to a slot is achievable with a 
 content element with select attribute.

content select=[my-attr='the slot value']

 I don't think defining a slot based on an attribute value is something we'd 
 like to support.

That is *literally* what your proposal already is, except limited to
only paying attention to the value of the content-slot attribute.

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote:
 Between content-slot-specified slots, attribute-specified slots,
 element-named slots, and everything-else-slots, we're now in a weird place
 where we've reinvented a micro-language with some, but not all, of the 
 power
 of CSS selectors. Is adding a new micro-language to the web platform worth
 helping implementers avoid the complexity of implementing CSS selector
 matching in this context?

 I don't think mapping an attribute value to a slot is achievable with a
 content element with select attribute.

 content select=[my-attr='the slot value']

 No. That's not what I'm talking here.  I'm talking about putting the
 attribute value into the insertion point in [1] [2] [3], not distributing an
 element based on an attribute value.

Oh, interesting.  That appears to be a complete non-sequitur, tho, as
no one has asked for anything like that.  It's *certainly* irrelevant
as a response to the text you quoted.

 On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote:
 I don't think defining a slot based on an attribute value is something we'd
 like to support.

 That is *literally* what your proposal already is, except limited to
 only paying attention to the value of the content-slot attribute.

 Distributing elements based on the value of a single well scoped attribute
 versus of an arbitrary attribute is A HUGE difference.

Interesting.  Why?  And why do you think the difference is significant
enough to justify such a limitation?  You seem to be okay with
distributing elements based on the *name* of an arbitrary attribute;
can you justify why that is so much better than using the value that
you're willing to allow it, but not the other?

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote:
 Hi Tab,

 Thanks for your feedback!

 A primary motivation for proposing names instead of CSS selectors to control
 distribution is to enable subclassing. We think it’s important for a
 subclass to be able to override a base class insertion point. That seems
 easier to achieve with a name. It lets content insertion points behave like
 named DOM-valued component parameters that can be overridden by subclasses.

 To use an example, consider the page template component example at
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this
 example, a base page template class defines a header slot. A university
 department wants to create a subclass of this template that partially
 populates some of the base class’ slots. In this case, it may want to add
 the department name to the header slot, then redefine an insertion point
 with the name that lets an individual page in that department add additional
 text to the header.

 The physics department page template subclass could then write something
 like this (following the proposal's syntax):

 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template

 If an instance of this page then says

 physics-department-page
   headerFaculty/header
 /physics-department-page

 then the rendered result shows “Physics Department Faculty” in the base
 template header.

 This is analogous to what typical OOP languages enable when a subclass
 overrides a base class property. In such languages, the subclass simply
 defines a property with the same name as a base class property. The
 subclass’ property implementation can invoke the base class property
 implementation if it wants. The model is fairly easy to understand and
 implement, because the properties are always identified by name.

 A similar result could theoretically be achieved with CSS selectors, but the
 approach feels looser and a bit unwieldy, particularly if there are not
 rigid conventions about how the content select clauses are written.
 Assuming it were possible to reproject into a base class’ shadow — and
 that’s not actually possible today — you’d have to write something like:

 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template

 So that approach could be made to work, but to me at least, feels harder,
 especially if the base class is using complex CSS selectors.

I'm not really seeing the complexity.  In particular, I'm not seeing
why content-slot/slot is easier than class/select.  For all simple
cases (class, attribute, tagname) it seems pretty much identical.
More complex selectors, like :nth-child(), might make it a bit more
difficult (as you have to match your markup to what the superclass is
expecting), but that's probably normally okay, and in problematic
cases is just because the superclass is being too clever.

On the other hand, requiring content-slot in order to place things in
anything but the default slot means you have to ugly up your markup
quite a bit.  It makes current UA-shadow-using elements, such as
details, impossible to duplicate, and makes all uses of shadow DOM
uglier and more verbose.

For example, I think tagname is a very common thing to select on.
details uses it, your fingers automatically used it before you
corrected your example, a number of Polymer examples use it, etc.
Requiring the use of header content-slot=header is adding 20
characters to the element.  A shadow-heavy page, such as some of the
Polymer examples, would have a relatively large amount of its page
weight being paid to this attribute scattered all over the place.

As Justin said, this seems to be extremely over-engineering towards
make subclass-and-reproject slightly more reliable, to the detriment
of every other case.  Subclass-and-reproject works just fine with
select='' unless the superclass's selector is too complex/specialized
to easily satisfy in your subclass's preferred markup; in the common
case of a tagname, class name, or attribute name, the two are
identical.

In return, content-slot makes the common case (just project into some
shadow) more verbose for the user, and make some cases, such as the
date-range-combo-box illustrated by Daniel earlier in the thread
https://gist.github.com/azakus/676590eb4d5b07b94428 impossible.

Overall, this feels like an over-optimization for implementation
complexity (matching content-slot to slot is easier than matching an
element to a selector) without fully considering the cost to the
author and user, which is a strong inversion of the priority of
constituencies.

~TJ

Re: Proposal for changes to manage Shadow DOM content distribution

[Tab Atkins Jr.]

On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote:
 I find it decidedly relevant given I'm pointing out that attribute-specified
 slots Domenic mentioned isn't what you described.  Since the only venue in
 which attribute-specified slots came up are [1], [2], and [3].  We're
 DEFINITELY NOT interested in filling slots based on values of arbitrary
 attributes.

 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
 [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

Apologies, I'd misread [1] and didn't realize it really was talking
about projecting the value of an attribute into the content of a slot.

(Though I'm confused by the vehemence of your denial here, given that
in [2] you said you could imagine that such a feature could be easily
added.)

~TJ

Re: Directory Upload Proposal

[Tab Atkins Jr.]

On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon seddon.r...@gmail.com wrote:
 To enable developers to build future interoperable solutions, we've
 drafted a proposal [4], with the helpful feedback of Mozilla and Google,
 that focuses strictly on providing the mechanisms necessary to enable
 directory uploads.

 The use of the dir attribute seems odd since I can already apply dir=rtl
 to an input to change the text direction.

Good catch; that's a fatal naming clash, and needs to be corrected.
The obvious one is to just expand out the name to directory.

~TJ

Re: =[xhr]

[Tab Atkins Jr.]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson k...@pure3interactive.com wrote:
 RE async: false being deprecated

 There's still occasionally a need for a call from client javascript back to
 server and wait on results. Example: an inline call from client javascript
 to PHP on server to authenticate an override password as part of a
 client-side operation. The client-side experience could be managed with a
 sane timeout param - eg return false if no response after X seconds (or ms).

Nothing prevents you from waiting on an XHR to return before
continuing.  Doing it with async operations is slightly more complex
than blocking with a sync operation, is all.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
 I don't understand why :host is a pseudo-class rather than a
 pseudo-element. My mental model of a pseudo-class is that it allows
 you to match an element based on a boolean internal slot of that
 element. :host is not that since e.g. * does not match :host as I
 understand it. That seems super weird. Why not just use ::host?

 Copying WebApps since this affects everyone caring about Shadow DOM.

Pseudo-elements are things that aren't DOM elements, but are created
by Selectors for the purpose of CSS to act like elements.

The host element is a real DOM element.  It just has special selection
behavior from inside its own shadow root, for practical reasons: there
are good use-cases for being able to style your host, but also a lot
for *not* doing so, and so mixing the host into the normal set of
elements leads to a large risk of accidentally selecting the host.
This is particularly true for things like class selectors; since the
*user* of the component is the one that controls what classes/etc are
set on the host element, it's very plausible that a class used inside
the shadow root for internal purposes could accidentally collide with
one used by the outer page for something completely different, and
cause unintentional styling issues.

Making the host element present in the shadow tree, but featureless
save for the :host and :host-context() pseudo-classes, was the
compromise that satisfies all of the use-cases adequately.

It's possible we could change how we define the concept of
pseudo-element so that it can sometimes refer to real elements that
just aren't ordinarily accessible, but I'm not sure that's necessary
or desirable at the moment.

On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote:
 We haven't really used (in the sense of shipping across browsers)
 pseudo-elements before for things that are both tree-like (i.e., not
 ::first-letter, ::first-line, or ::selection) and not leaves of the
 tree.  (Gecko doesn't implement any pseudo-elements that can have
 other selectors to their right.  I'm not sure if other engines
 have.)

 I'd be a little worried about ease of implementation, and doing so
 without disabling a bunch of selector-related optimizations that
 we'd rather have.

 At some point we probably do want to have this sort of
 pseudo-element, but it's certainly adding an additional dependency
 on to this spec.

The ::shadow and ::content pseudo-elements are this way (tree-like,
and not leaves).  We implement them in Blink currently, at least to
some extent.  (Not sure if it's just selector tricks, or if we do it
properly so that, for example, inheritance works.)

On Mon, Apr 27, 2015 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
 Thanks, that example has another confusing bit, ::content. As far as I
 can tell ::content is not actually an element that ends up in the
 tree. It would make more sense for that to be a named-combinator of
 sorts. (And given ::content allowing selectors on the right hand, it's
 now yet more unclear why :host is not ::host.)

It's a (pseudo-)element in the tree, it's just required to not
generate a box.  Having ::content (and ::shadow) be pseudo-elements
lets you do a few useful things: you can use other combinators (child
*or* descendant, depending on what you need) and you can set inherited
properties to cascade down to all the children (especially useful for,
for example, setting 'color' of direct text node children, which can
appear in a shadow root or in a content with no select='', and can't
be targeted by a selector otherwise).  I did originally use
combinators for this, but they're less useful for the reasons just
listed.

(This was explicitly discussed in a telcon, when I noted that
sometimes you want to select the top-level things in a shadow tree
or distribution list, and sometimes all the things.  I had proposed
two versions of each combinator, or an argument to a named combinator
(like /shadow / versus /shadow /), but someone else (I think it was
fantasai?) suggested using a pseudo-element instead, and it turned out
to be a pretty good suggestion.)

~TJ

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Tab Atkins Jr.]

On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
 IMO, the appeal of this proposal is that it's a small change to the current 
 spec and avoids changing user expectations about the state of the dom and 
 can explain the two declarative proposals for distribution.

 It seems like with this API, we’d have to make O(n^k) calls where n is the 
 number of distribution candidates and k is the number of insertion points, 
 and that’s bad.  Or am I misunderstanding your design?

 I think you've understood the proposed design. As you noted, the cost is 
 actually O(n*k). In our use cases, k is generally very small.

 I don't think we want to introduce O(nk) algorithm. Pretty much every 
 browser optimization we implement these days are removing O(n^2) algorithms 
 in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because 
 we can't even theoretically optimize it away.

 You're aware, obviously, that O(n^2) is a far different beast than
 O(nk).  If k is generally small, which it is, O(nk) is basically just
 O(n) with a constant factor applied.

To make it clear: I'm not trying to troll Ryosuke here.

He argued that we don't want to add new O(n^2) algorithms if we can
help it, and that we prefer O(n).  (Uncontroversial.)

He then further said that an O(nk) algorithm is sufficiently close to
O(n^2) that he'd similarly like to avoid it.  I'm trying to
reiterate/expand on Steve's message here, that the k value in question
is usually very small, relative to the value of n, so in practice this
O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to
new O(n^2) algorithms may be mistargeted here.

~TJ

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Tab Atkins Jr.]

On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote:
 IMO, the appeal of this proposal is that it's a small change to the current 
 spec and avoids changing user expectations about the state of the dom and 
 can explain the two declarative proposals for distribution.

 It seems like with this API, we’d have to make O(n^k) calls where n is the 
 number of distribution candidates and k is the number of insertion points, 
 and that’s bad.  Or am I misunderstanding your design?

 I think you've understood the proposed design. As you noted, the cost is 
 actually O(n*k). In our use cases, k is generally very small.

 I don't think we want to introduce O(nk) algorithm. Pretty much every browser 
 optimization we implement these days are removing O(n^2) algorithms in the 
 favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because we can't 
 even theoretically optimize it away.

You're aware, obviously, that O(n^2) is a far different beast than
O(nk).  If k is generally small, which it is, O(nk) is basically just
O(n) with a constant factor applied.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Pseudo-elements are things that aren't DOM elements, but are created
 by Selectors for the purpose of CSS to act like elements.

 That's not true for e.g. ::-webkit-slider-thumb as I already indicated.

Sure it is.  input type=range has no children, and the shadow tree
is sealed, so the fact that a shadow tree even exists is hidden from
DOM.  As far as CSS is capable of discerning, there is no thumb
element, so the pseudo-element makes sense.

 The host element is a real DOM element.  It just has special selection
 behavior from inside its own shadow root, for practical reasons: there
 are good use-cases for being able to style your host, but also a lot
 for *not* doing so, and so mixing the host into the normal set of
 elements leads to a large risk of accidentally selecting the host.
 This is particularly true for things like class selectors; since the
 *user* of the component is the one that controls what classes/etc are
 set on the host element, it's very plausible that a class used inside
 the shadow root for internal purposes could accidentally collide with
 one used by the outer page for something completely different, and
 cause unintentional styling issues.

 Making the host element present in the shadow tree, but featureless
 save for the :host and :host-context() pseudo-classes, was the
 compromise that satisfies all of the use-cases adequately.

 My problem is not with the ability to address the host element, but by
 addressing it through a pseudo-class, which has so far only been used
 for matching elements in the tree that have a particular internal
 slot.

I don't understand what distinction you're trying to draw here.  Can
you elaborate?

 It's possible we could change how we define the concept of
 pseudo-element so that it can sometimes refer to real elements that
 just aren't ordinarily accessible, but I'm not sure that's necessary
 or desirable at the moment.

 Well, it would for instance open up the possibility of using :host in
 the light tree to match elements that are host elements.

That's just a naming-collision thing.  We can come up with a different
name for either has a shadow tree or is the host element of the
current shadow tree; it's just that right now, the latter has claimed
the name :host.

I certainly don't want to create both a pseudo-class and
pseudo-element with the same name if I can help it (or at least, not
ones that refer to similar things); the distinction between
pseudo-classes and pseudo-elements in most author's minds is already
tenuous.  (Definitely not helped by the legacy :before/etc syntax.)

~TJ

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Tab Atkins Jr.]

On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote:
 One thing that worries me about the `distribute` callback approach (a.k.a.
 Anne's approach) is that it bakes distribution algorithm into the platform
 without us having thoroughly studied how subclassing will be done upfront.

 Mozilla tried to solve this problem with XBS, and they seem to think what
 they have isn't really great. Google has spent multiple years working on
 this problem but they come around to say their solution, multiple
 generations of shadow DOM, may not be as great as they thought it would be.
 Given that, I'm quite terrified of making the same mistake in spec'ing how
 distribution works and later regretting it.

 At least the way I understand it, multiple shadow roots per element and
 distributions are largely orthogonal bits of machinery that solve largely
 orthogonal problems.

Yes.  Distribution is mainly about making composition of components
work seamlessly, so you can easily pass elements from your light dom
into some components you're using inside your shadow dom.  Without
distribution, you're stuck with either:

* avoiding content entirely and literally moving the elements from
the light dom to your shadow tree (like, appendChild() the nodes
themselves), which means the outer page no longer has access to the
elements for their own styling or scripting purposes (this is
terribad, obviously), or
* components have to be explicitly written with the expectation of
being composed into other components, writing their own content
select *to target the content elements of the outer shadow*, which
is also extremely terribad.

Distribution makes composition *work*, in a fundamental way.  Without
it, you simply don't have the ability to use components inside of
components except in special cases.

~TJ

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Tab Atkins Jr.]

On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote:
 One thing that worries me about the `distribute` callback approach (a.k.a.
 Anne's approach) is that it bakes distribution algorithm into the platform
 without us having thoroughly studied how subclassing will be done upfront.

 Mozilla tried to solve this problem with XBS, and they seem to think what
 they have isn't really great. Google has spent multiple years working on
 this problem but they come around to say their solution, multiple
 generations of shadow DOM, may not be as great as they thought it would be.
 Given that, I'm quite terrified of making the same mistake in spec'ing how
 distribution works and later regretting it.

 At least the way I understand it, multiple shadow roots per element and
 distributions are largely orthogonal bits of machinery that solve largely
 orthogonal problems.

 Yes.  Distribution is mainly about making composition of components
 work seamlessly, so you can easily pass elements from your light dom
 into some components you're using inside your shadow dom.  Without
 distribution, you're stuck with either:

 As I clarified my point in another email, neither I nor anyone else is 
 questioning the value of the first-degree of node distribution from the 
 light DOM into insertion points of a shadow DOM.  What I'm questioning is 
 the value of the capability to selectively re-distribute those nodes in a 
 tree with nested shadow DOMs.

 * components have to be explicitly written with the expectation of
 being composed into other components, writing their own content
 select *to target the content elements of the outer shadow*, which
 is also extremely terribad.

 Could you give me a concrete use case in which such inspection of content 
 elements in the light DOM is required without multiple generations of shadow 
 DOM?  In all the use cases I've studied without multiple generations of 
 shadow DOM, none required the ability to filter nodes inside a content 
 element.

 Distribution makes composition *work*, in a fundamental way.  Without it, 
 you simply don't have the ability to use components inside of components 
 except in special cases.

 Could you give us a concrete example in which selective re-distribution of 
 nodes are required? That'll settle this discussion/question altogether.

I'll let a Polymer person provide a concrete example, as they're the
ones that originally brought up redistribution and convinced us it was
needed, but imagine literally any component that uses more than one
content (so you can't get away with just distributing the content
element itself), being used inside of some other component that wants
to pass some of its light-dom children to the nested component.

Without redistribution, you can only nest components (using one
component inside the shadow dom of another) if you either provide
contents directly to the nested component (no content) or the nested
component only has a single distribution point in its own shadow.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 It's certainly no weirder, imo, than having a pseudo-element that
 doesn't actually live in any element's pseudo-tree, but instead just
 lives in the normal DOM, but can only be selected by using a
 pseudo-element selector with no LHS.  Pseudo-elements are fucked,
 unfortunately, but we have to live with their quirks, and those quirks
 make them really bad for this particular case.

 Why?

As was said before, pseudo-elements have to be attached to a real
element.  Pseudo-element selectors have a built-in combinator; they're
actually complex selectors all by themselves.  (This isn't properly
reflected in Selectors right now; I haven't made the edits to the data
model that need to happen to make pseudo-elements work properly.)

But the host element isn't attached to any of the elements in its
shadow tree; it's a *parent* of all of them.  If we ignored this and
let it attach to an element, which one?  There's no single top-most
element to privilege.  If we attach to *all* of them, then we get the
bizarre result that #foo::host  #foo might actually select
something.  Having lots of elements share the same pseudo-element is
also unprecedented currently.

Pseudo-elements also, because they're complex selectors, aren't usable
everywhere that other selectors are.  If you have a context that only
accepts simple or compound selectors (as a filter, for instance),
pseudo-elements aren't available.

So if we use :host, we have to invent a new concept to make it work
(featureless). If we use ::host, we have to invent a new concept to
make it work (new ways for pseudo-elements to exist and be targeted).
I think the latter is weirder than the former.

 And again, from the perspective of the shadow tree, the host element
 is not part of its normal DOM. The shadow tree is its normal DOM. This
 is the same as ::-webkit-range-thumb. From the perspective of the
 light DOM, that element is not part of its normal DOM. But it is part
 of the composed DOM.

And again, it depends on what level of authority you're talking about.
As far as the outer page is concerned, the input element is empty,
and ::webkit-range-thumb is a fictitious pseudo-element created solely
by the platform.  There's no real DOM underlying it, because the
shadow dom is fully sealed, so anything inside of it is dead.

From the platform's perspective, sure, there's a real element under
there.  And the platform does get special powers that the page might
not have.  But the fact that input is implemented with shadow DOM is
an undetectable implementation detail at the moment.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org wrote:
 That's still true if you use ::host, what is the thing on the left hand side
 the ::host lives on? I'm not aware of any pseudo element that's not
 connected to another element such that you couldn't write {thing}::pseudo.

 ::selection?

::selection has a host element.  If you use it by itself it just means
you're selecting *::selection.

 But maybe you're right and the whole
 pseudo-class/pseudo-element distinction is rather meaningless. But at
 least pseudo-class til date made some sense.

I still don't understand what you find wrong with this.  It's not that
:host() [can] match an element that cannot otherwise be matched,
it's that the host element element is featureless, save for the
ability to match :host.  (That's the definition of a featureless
element - it's allowed to specify particular things that can still
match it.)  In other words, it's not :host that's magical, it's the
host element itself that's magical.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Mon, May 4, 2015 at 9:38 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote:
 But maybe you're right and the whole
 pseudo-class/pseudo-element distinction is rather meaningless. But at
 least pseudo-class til date made some sense.

 I still don't understand what you find wrong with this.  It's not that
 :host() [can] match an element that cannot otherwise be matched,
 it's that the host element element is featureless, save for the
 ability to match :host.  (That's the definition of a featureless
 element - it's allowed to specify particular things that can still
 match it.)  In other words, it's not :host that's magical, it's the
 host element itself that's magical.

 So :host:hover would not work? I guess you would have to spell that
 :host(:hover)? Because although it does not have features, it has
 features inside the parenthesis?

Correct. The functional :host() pseudo-class can match the selector
against the *real* host element that hosts the shadow tree (and
:host-context() can do so for the entire shadow-piercing ancestor
tree).  But normal selectors inside a shadow tree only see the
featureless version of the host element that lives inside of the
shadow tree.

 Was this concept introduced for other scenarios or just for :host?
 Seems like a very weird rationalization.

Yeah, it was introduced to give the host element the selection
behavior we wanted (I explained this in more detail in my first post
in the thread).

It's certainly no weirder, imo, than having a pseudo-element that
doesn't actually live in any element's pseudo-tree, but instead just
lives in the normal DOM, but can only be selected by using a
pseudo-element selector with no LHS.  Pseudo-elements are fucked,
unfortunately, but we have to live with their quirks, and those quirks
make them really bad for this particular case.

~TJ

Re: :host pseudo-class

[Tab Atkins Jr.]

On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote:
 On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote:
 I don't understand why :host is a pseudo-class rather than a
 pseudo-element. My mental model of a pseudo-class is that it allows
 you to match an element based on a boolean internal slot of that
 element. :host is not that since e.g. * does not match :host as I
 understand it. That seems super weird. Why not just use ::host?

 Copying WebApps since this affects everyone caring about Shadow DOM.

 We haven't really used (in the sense of shipping across browsers)
 pseudo-elements before for things that are both tree-like (i.e., not
 ::first-letter, ::first-line, or ::selection) and not leaves of the
 tree.  (Gecko doesn't implement any pseudo-elements that can have
 other selectors to their right.  I'm not sure if other engines
 have.)

 I'd be a little worried about ease of implementation, and doing so
 without disabling a bunch of selector-related optimizations that
 we'd rather have.

 At some point we probably do want to have this sort of
 pseudo-element, but it's certainly adding an additional dependency
 on to this spec.

 My understanding is that the question here isn't what is being
 matched, but rather what syntax to use for the selector. I.e. in both
 cases the thing that the selector is matching is the DocumentFragment
 which is the root of the shadow DOM.

As Anne said, no, the thing matched is the actual host element.  But
otherwise, yeah, we're just debating the syntax of how to select that
(while obeying the constraints I outlined in my first post to this
thread).

 If implementing :host is easier than ::host, then it seems like the
 implementation could always convert the pseudo-element into a
 pseudo-class at parse time. That should make the implementation the
 same other than in the parser. Though maybe the concern here is about
 parser complexity?

It's not about parser complexity. (dbaron did use that as an argument
against ::host, but I'm not making that argument; Blink's parser has
no problem with it.)  It's about hitting the (admittedly complex)
constraints sanely within the existing Selectors model.

~TJ

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Tab Atkins Jr.]

On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote:
 On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote:
 We can solve this
 problem by running the distribution code in a separate scripting context
 with a restricted (distribution specific) API as is being discussed for
 other extension points in the platform.

 That seems like a lot of added complexity, but yeah, that would be an
 option I suppose. Dimitri added something like this to the imperative
 API proposal page a couple of days ago.


 One thing to consider here is that we very much consider distribution a
 style concept. It's about computing who you inherit style from and where you
 should be in the box tree. It just so happens it's also leveraged in event
 dispatch too (like pointer-events). It happens asynchronously from DOM
 mutation as needed just like style and reflow though.

 I don't really see it that way. The render tree is still computed from
 the composed tree. The composed tree is still a DOM tree, just
 composed from various other trees. In the open case you can access
 it synchronously through various APIs (e.g.  if we keep that for
 querySelector() selectors and also deepPath).

 I agree. I don't see any reason node distribution should be considered as a 
 style concept. It's a DOM concept. There is no CSS involved here.

Yes there is.  As Elliot stated in the elided parts of his quoted
response above, most of the places where we update distribution are
for CSS or related concerns:

# 3 event related
# 3 shadow dom JS api
# 9 style (one of these is flushing style)
# 1 query selector (for ::content and :host-context)

 I have issues with the argument that we should do it lazily.  On one hand, if 
 node distribution is so expensive that we need to do it lazily, then it's 
 unacceptable to make event dispatching so much slower.  On the other hand, if 
 node distribution is fast, as it should be, then there is no reason we need 
 to do it lazily.

 The problem is really the redistributions. If we instead had explicit 
 insertion points under each shadow host, then we wouldn't really need 
 redistributions at all, and node distribution can happen in O(1) per child 
 change.

As repeatedly stated, redistribution appears to be a necessity for
composition to work in all but the most trivial cases.

~TJ

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote:
 * This spec is now using Github https://w3c.github.io/FileAPI/ and the ED
 is https://w3c.github.io/FileAPI/Overview.html. PRs are welcome and
 encouraged. (I think it would be useful if this spec used ReSpec and if
 anyone can help with that port, please do contact me.)

This was actually already next on my list of specs to Bikeshed, as
soon as I finish DOM (which I'm doing as I type this).  WebIDL-heavy
specs benefit a lot from being Bikeshedded, so all the IDL definitions
get properly marked up for the linking database. ^_^

~TJ

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com wrote:
 Hi All,

 A new Working Draft publication of File API is planned for April 21 using
 the following version as the basis:

  https://w3c.github.io/FileAPI/TR.html

Note that this version appears to be based off the Overview-FAWD.xml
file in the CVS repo, which hasn't been touched in 5 years.  The file
Overview-FA.xml is much more recent and appears to be what the
current file at http://www.w3.org/TR/FileAPI/ is based on (note the
relative positions of the FileList and Blob sections - in
Overview-FA.xml and the current TR, FileList comes first).  I suspect,
then, that the file you're referencing is out-of-date and shouldn't be
used.

~TJ

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 3:00 PM, Arthur Barstow art.bars...@gmail.com wrote:
 On 4/15/15 5:56 PM, Tab Atkins Jr. wrote:

 On Wed, Apr 15, 2015 at 7:23 AM, Arthur Barstow art.bars...@gmail.com
 wrote:

   https://w3c.github.io/FileAPI/TR.html

 Note that this version appears to be based off the Overview-FAWD.xml
 file in the CVS repo, which hasn't been touched in 5 years.  The file
 Overview-FA.xml is much more recent and appears to be what the
 current file at http://www.w3.org/TR/FileAPI/ is based on (note the
 relative positions of the FileList and Blob sections - in
 Overview-FA.xml and the current TR, FileList comes first).  I suspect,
 then, that the file you're referencing is out-of-date and shouldn't be
 used.


 I didn't use either of those files but Overview.html, as directed by Arun.

 (He told me he stopped editing the Overview-FA.xml file some type ago).

Oh god, you're right, it looks like Arun has been directly editting
the generated HTML since Jan 2013.  Confusingly, there's a single
commit to Overview-FA.xml in Nov 2014 which just updates the
Prev/Current links in the header; the immediately preceding commit is
from Jan 2013, though, while Overview.html has been editted repeatedly
in that span.

Ugh, working with the XML was a lot easier.  Darn.

Arun, buddy, I'm sorry you had to go through the pain of directly
editting generated HTML.

~TJ

Re: PSA: publishing new WD of File API on April 21

[Tab Atkins Jr.]

On Wed, Apr 15, 2015 at 12:54 PM, Martin Thomson
martin.thom...@gmail.com wrote:
 On 15 April 2015 at 07:26, Arthur Barstow art.bars...@gmail.com wrote:
 * This spec is now using Github https://w3c.github.io/FileAPI/


 That repo is actually https://github.com/w3c/FileAPI/.


 Since the most obvious github.io link is currently broken, would it
 make sense to move Overview.html to index.html?  Does the name
 Overview.html hold special meaning?

No, it's just an older tradition for specs in some working groups.  I
also recommend using index.html as the generated file name (and am
doing so in my Bikeshedding, which is now underway).

~TJ

Re: Writing spec algorithms in ES6?

[Tab Atkins Jr.]

On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/11/15 4:32 PM, Dimitri Glazkov wrote:
 I noticed that the CSS Color Module Level 4 actually does this, and it
 seems pretty nice:
 http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor

 I should note that the ES code there produces semantics that don't match the
 IDL in this spec (or is complete nonsense, depending on how literally you
 choose to read it).

Yes, the code currently there is... loose.  There's a lot of problems
trying to map IDL directly into ES without a lot of boilerplate.

 So there are basically at least two problems here:

 1)  You have to clearly delineate when you're working with JS values and
 when you're working with IDL values, to the extent that these are not the
 same thing.

 2)  You have to clearly delineate which bits of JS run in the page global
 and which bits run in some other clean global and which bits run in the page
 global but have access to some clean intrinsics somehow.

 I would actually prefer some sort of pseudocode that is _not_ JS-looking,
 just so people don't accidentally screw this up.

I actually rather like using JS code for these; it's familiar and easy
to read.  But yeah, Domenic outlines some of the things we'd have to
change before this was actually useful.

I wrote Color the way I did because writing math in prose is
*incredibly* awkward, but writing it in ES-ese is *even more
incredibly awkward*.  So for now, I opted for the insufficient third
alternative of JS, if we handwave and pretend all the obvious
problems don't occur.

~TJ

Re: Shadow DOM spec bugs will be migrated into GitHub issues

[Tab Atkins Jr.]

Note for the future (to you and editors of other specs in WebApps):

Before doing this kind of mass bug editting, please turn off the
automatic email to public-webapps.  If you can't do that yourself,
Mike Smith can (at least, he's done it in the past).  That prevents
the mass flood of bugspam from clogging up people's inboxes. ^_^

~TJ

On Tue, May 26, 2015 at 8:30 PM, Hayato Ito hay...@google.com wrote:
 PSA: I've finished the migration. All open bugs are now marked as MOVED
 with a link to the corresponding GitHub issue.

 On Mon, May 25, 2015 at 5:58 PM Hayato Ito hay...@google.com wrote:

 Regarding with the Shadow DOM spec, more and more workflows are happening
 [1] on GitHub w3c/webcomponents repository recently.
 Therefore, I am thinking about migrating the bugs of the Shadow DOM spec,
 from the bugzilla [2], to the GitHub issues [3], as some of other specs are
 already doing so.

 As an experiment, I've just migrated the existing open bugs on the
 bugzilla to the GitHub issues, by a tiny script I've written using GitHub
 APIs.

 Unless there is an objection to the migration, I am going to close the
 existing open Shadow DOM spec bugs on the bugzilla, with a link to the
 corresponding bug on the GitHub issues.

 Please let me know if you have a concern.

 [1] https://github.com/w3c/webcomponents/commits/gh-pages
 [2] https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
 [3] https://github.com/w3c/webcomponents/issues

Re: [shadow-dom] ::before/after on shadow hosts

[Tab Atkins Jr.]

All right, sounds pretty unanimous that #2 (current behavior) is what
we should go with. I'll clarify the Scoping spec.  Thanks!

~TJ

[shadow-dom] ::before/after on shadow hosts

[Tab Atkins Jr.]

I was recently pointed to this StackOverflow thread
http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/
which asks what happens to ::before and ::after on shadow hosts, as
it's not clear from the specs.  I had to admit that I hadn't thought
of this corner-case, and it wasn't clear what the answer was!

In particular, there seem to be two reasonable options:

1. ::before and ::after are *basically* children of the host element,
so they get suppressed when the shadow contents are displayed

2. ::before and ::after aren't *really* children of the host element,
so they still show up before/after the shadow contents.

According to the SO thread (I haven't tested this myself), Firefox and
Chrome both settled on #2.  I'm fine to spec this in the Scoping
module, I just wanted to be sure this was the answer we wanted.

~TJ

Re: PSA: publish WD of WebIDL Level 1

[Tab Atkins Jr.]

On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote:
 Hi All,

 This is heads-up re the intent to publish a Working Draft of WebIDL Level
 1 (on or around August 4) using Yves' document as the basis and a new
 shortname of WebIDL-1:

 https://ylafon.github.io/webidl/publications/fpwd-20150730.html

 There is an open question about what should happen with TR/WebIDL/ (which
 now is the 2012 Candidate Recommendation). One option is to serve it as
 WebIDL-1. Another option is to replace it with the latest version of
 Cameron's Editor's Draft. A third option is to make it some type of landing
 page the user can use to load the various versions. Feedback on these
 options is welcome and the default (if there are no non-resolvable issues)
 is to go with option #2 (Yves' preference).

The CSSWG always points the non-leveled url to the latest spec.  (#2,
if I'm counting your options correctly)

~TJ

Re: PSA: publish WD of WebIDL Level 1

[Tab Atkins Jr.]

On Fri, Aug 7, 2015 at 9:23 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
 This is, at a minimum, incremental goodness. It's better than leaving the 
 prior L1 published document around--which already tripped up a few folks on 
 my team recently. I strongly +1 it.

There are alternatives!  In particular, you can publish a gravestone
revision.  Bikeshed has boilerplate for this you can steal the wording
of:

```
details open class='annoying-warning'
  summaryThis Document Is Obsolete and Has Been Replaced/summary
  p
This specification is obsolete and has been replaced by the
document at a href=[REPLACEDBY][REPLACEDBY]/a.
Do not attempt to implement this specification.
Do not refer to this specification except as a historical artifact.
/details
```

Just publish a new WD containing *only* that as the content, and
you're golden.

For bonus points, publish revisions of all the dated webidl1 specs,
with that as an actual warning (no need to wipe out their contents).
Look at the styling of the message on
https://tabatkins.github.io/specs/respimg/ for a good example that
makes it impossible to miss that you're looking at an obsolete spec.

~TJ

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Tab Atkins Jr.]

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:
> Hi, Eliott–
>
> Good question.
>
> I don't have a great answer yet, but this is something that will need to be
> worked out with Shadow DOM, not just for this spec, but for Selection API
> and others, as well as to CSS, which has some Range-like styling.

CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ

Re: Normative references to Workers.

[Tab Atkins Jr.]

On Tue, Sep 15, 2015 at 10:31 AM, Mike West  wrote:
> The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML
> spec for the
> "set up a worker environment settings object" algorithm[2], as the Web
> Workers Candidate Recommendation from May 2012[3] substantially predates the
> entire concept of a "settings object", and because the WHATWG is the group
> where work on Workers seems to be being done.
>
> This referential choice was flagged during a discussion of transitioning the
> Upgrade spec to CR, where it was noted that the Web Workers editor's draft
> from May 2014 does contain the referenced concept[4].
>
> It seems appropriate, then, to bring the question to this group: does
> WebApps intend to update the Workers draft in TR? If so, is there a path
> forward to aligning the Workers document with the work that's happened over
> the last year and a half in WHATWG? Alternatively, does WebApps intend to
> drop work on Workers in favor of the WHATWG's document?

Agreed with Hixie; the WHATWG spec is the most recent normative
version of that section, and should be referenced instead.  Remember,
there's nothing wrong with reffing WHATWG specs.  It will not delay or
hamper your publication or Rec-track advancement, despite the
occasional misinformed complaint from someone not aware of the
policies.

~TJ

Re: Indexed DB + Promises

[Tab Atkins Jr.]

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola  wrote:
> I guess part of the question is, does this add enough value, or will authors 
> still prefer wrapper libraries, which can afford to throw away backward 
> compatibility in order to avoid these ergonomic problems? From that 
> perspective, the addition of waitUntil or a similar primitive to allow better 
> control over transaction lifecycle is crucial, since it will enable better 
> wrapper libraries. But the .promise and .complete properties end up feeling 
> like halfway measures, compared to the usability gains a wrapper can achieve. 
> Maybe they are still worthwhile though, despite their flaws. You probably 
> have a better sense of what authors have been asking for here than I do.

Remember that the *entire point* of IDB was to provide a "low-level"
set of functionality, and then to add a sugar layer on top once
authors had explored the space a bit and shown what would be most
useful.

I'd prefer we kept with that approach, and defined a consistent,
easy-to-use sugar layer that's just built with IDB primitives
underneath, rather than trying to upgrade the IDB primitives into more
usable forms that end up being inconsistent or difficult to use.

~TJ

Re: Indexed DB + Promises

[Tab Atkins Jr.]

On Wed, Sep 30, 2015 at 11:07 AM, Kyle Huey <m...@kylehuey.com> wrote:
> On Wed, Sep 30, 2015 at 10:50 AM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
>> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d...@domenic.me> wrote:
>>> I guess part of the question is, does this add enough value, or will 
>>> authors still prefer wrapper libraries, which can afford to throw away 
>>> backward compatibility in order to avoid these ergonomic problems? From 
>>> that perspective, the addition of waitUntil or a similar primitive to allow 
>>> better control over transaction lifecycle is crucial, since it will enable 
>>> better wrapper libraries. But the .promise and .complete properties end up 
>>> feeling like halfway measures, compared to the usability gains a wrapper 
>>> can achieve. Maybe they are still worthwhile though, despite their flaws. 
>>> You probably have a better sense of what authors have been asking for here 
>>> than I do.
>>
>> Remember that the *entire point* of IDB was to provide a "low-level"
>> set of functionality, and then to add a sugar layer on top once
>> authors had explored the space a bit and shown what would be most
>> useful.
>>
>> I'd prefer we kept with that approach, and defined a consistent,
>> easy-to-use sugar layer that's just built with IDB primitives
>> underneath, rather than trying to upgrade the IDB primitives into more
>> usable forms that end up being inconsistent or difficult to use.
>
> At a bare minimum we need to actually specify how transaction
> lifetimes interact with tasks, microtasks, etc.  Especially since the
> behavior differs between Gecko and Blink (or did, the last time I
> checked).
>
> waitUntil() alone is a pretty large change to IDB semantics. Somebody
> mentioned earlier that you can get this behavior today which is true,
> but it requires you to continually issue "keep-alive" read requests to
> the transaction, so it's fairly obvious you aren't using it as
> intended.

Yeah, any necessary extensions to the underlying "bare" IDB semantics
that need to be made to support the sugar layer are of course
appropriate; they indicate an impedance mismatch that we need to
address for usability.

~TJ

Re: Shadow DOM and alternate stylesheets

[Tab Atkins Jr.]

On Tue, Dec 8, 2015 at 4:43 AM, Rune Lillesveen  wrote:
> what should happen with the title attribute of style elements in Shadow DOM?
>
> In Blink you can currently select style elements in shadow trees based
> on the alternate stylesheet name set for the document. You even set
> the preferred stylesheet using the title on style elements inside
> shadow trees. Perhaps the title element should be ignored on style
> elements in shadow trees?

I agree.

~TJ

Re: [XHR]

[Tab Atkins Jr.]

On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee
 wrote:
> On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen
>  wrote:
>> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
>>  wrote:
>>
>> > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse
>> > the
>> > chunked transfer coding”. The logical interpretation of this is that
>> > whenever possible HTTP recipients should deliver the chunks to the
>> > application as they are received, rather than waiting for the entire
>> > response to be received before delivering anything.
>> >
>> > In the latest version this can only be done for “text” responses. For
>> > any
>> > other type of response, the “response” attribute returns “null” until
>> > the
>> > transmission is completed.
>>
>> How would you parse for example an incomplete JSON source to expose an
>> object? Or incomplete XML markup to create a document? Exposing
>> partial responses for text makes sense - for other types of data
>> perhaps not so much.
>
> If I understand correctly, streams [1] with fetch should solve this
> use-case.
>
> [1] https://streams.spec.whatwg.org/

No, streams do not solve the problem of "how do you present a
partially-downloaded JSON object".  They handle chunked data *better*,
so they'll improve "text" response handling, but there's still the
fundamental problem that an incomplete JSON or XML document can't, in
general, be reasonably parsed into a result.  Neither format is
designed for streaming.

(This is annoying - it would be nice to have a streaming-friendly JSON
format.  There are some XML variants that are streaming-friendly, but
not "normal" XML.)

~TJ

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

[Tab Atkins Jr.]

On Mon, Apr 25, 2016 at 10:06 AM, 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-*'.)

We already have a similar restriction - custom elements names must
*contain* a dash.

~TJ

Re: [Custom Elements] Not requiring hyphens in names.

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea  wrote:
> What if custom Elements simply override existing ones then?
>
> ```js
> shadowRoot.registerElement('div', MyElement)
> ```

That means we lose the lingua franca that HTML provides; two
independent libraries can't ever depend on the core HTML elements,
because the other library might have overridden some of them.

Having a well-known common API is worthwhile.  (JS technically has
this problem, but replacing built-ins, when it's done, is typically
just to *expand* them.  And once modules finally ship, we'll have a
built-in module with pristine versions of all the built-ins, too.)

> If overriding native elements was documented, it'd be fine. By
> default, a blank document or shadow root has no elements registered,
> so  would use the native DIV. But, why not let the user define
> what a  is? There could optionally be a warning outputted to
> console:
>
> ```
> Warning: DIV was overridden: /path/to/some/file.js:123:4
> ```

This means every website that overrides any built-in element will have
never-ending console spam, which isn't great.

~TJ

Re: [Custom Elements] Not requiring hyphens in names.

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea  wrote:
> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have   
>  , with the possible exception that we can't override the
> native elements.

This would prevent us from ever adding any new elements to the
language, or at least require us to do real-world usage checks and
avoid names that would break too many pages if we took it over.
Requiring a dash is a minimal cost to element authors, and permanently
avoids any clashes.

This is similar to CSS requiring custom properties to start with a
double-dash, like --foo.

~TJ

Re: Service Worker issues

[Tab Atkins Jr.]

> caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys())
> Promise { : "pending" }

Note that this test will *not* tell you whether or not c.keys()
returns a promise; the .then callback is allowed to return a
non-promise, and .then() always returns a promise regardless.  You
have to log the return value of c.keys() directly.

~TJ