[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669

--- Comment #21 from brian kardell <bkardell@gmail.com> ---
(In reply to comment #20)
> IMHO the fallback element is more critical than the Web component. The
> component is a way to augment an element with more power, but it's just a
> variant of the fallback element.

 > To clarify, when I say "<input/foo>", I mean that's literally an <input>
> element, with the "foo" component bound to it. It's tag name is "input". It
> implements HTMLInputElement. 
> I'm fine with saying that the component can declare what element it's
> allowed to be bound to, so that "<div/foo>" just fails to bind (same as
> "<div>").

I'm not saying this to throw it back and downplay what you are saying - I'm
just curious:  How many things do you think really could do this vs how many
things will likely use div as the fallback element and be not actually very
useful in any way without a component?


> Just having the fallback defined in the component is insufficient because
> it's in the page that you need to know what kind of element it is, for
> fallback in legacy UAs or non-Web-component UAs, for validation, for
> authoring sanity, for semantic analysis, etc. Requiring that someone who's
> editing the page know how all the components are defined is poor, IMHO.

I think you misunderstood me there.. 

I am saying that all other concerns about what we mean by "is" or anything else
aside: I can see some kind of argument that allowing the _page author_ to
provide a fallback could be a nice feature even if you don't only consider old
browsers.  For example: It might be the case that only during the process of
upgrade you could find out that this browser doesn't support one thing that is
just too critical not to have.  It might be nice if you could just throw an
exception (or something) and prevent the upgrade, causing the fallback provided
by the author.  I actually have something like this in one of my projects and
it's handy because when something fails they are actually in the best position
to say what should happen. I was suggesting that daniel and others think about
it in those terms and see what they think about something more along the lines
of embed/object or noscript kind of fallback which would address that case: 
You aren't saying "This _is_ the embedded object" you are saying "This is what
you get because the embedded object (for whatever reason) couldn't be
embedded."  


My position here is that I expect that the majority of cases won't actually be
as simple as "extend  input" or "extend select" in a very meaningful way (look
at pretty much all of the examples shown at Google IO), but what Dimitri has
provided with <element> and shadow and maybe even template gives a lot of
ability to go way into it and determine what it really is with new tech. And
that in the "unsupported" scenario - you probably don't _want_ to just fall
back to the div you probably want to fall back to something else entirely...


I suppose there is an opportunity for the component to take fallback as input
in some cases, but I think that isn't always true either.  

I'd like to hear what others think about the value of author defined "fallback"
being: a) the same element b) something else - or c) irrelevant, it is just
ignored.  Maybe this is the wrong place for such a discussion.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 5 January 2013 01:12:42 UTC