[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 #19 from brian kardell <bkardell@gmail.com> ---
(In reply to comment #16)
> (In reply to comment #14)
> > 
> >    The custom tag name case:
> > 
> >    <x-slideshow class="outer pretty-block">
> >      <div class="box-shadowed">
> >        ...
> >      </div>
> > 
> >      <div class="box-shadowed">
> >        ...
> >      </div>
> >    </x-slideshow>
> > 
> > Which one clearly, immediately, obviously tells me as a view source user
> > that it is a slideshow?
> 
> Neither. The term "slideshow" is an opaque string with no defined meaning in
> HTML.

Hixie, 

True enough, but slideshow does have a meaning in the definition of the web
component and that definition provides the exact sort of meaning you are
looking for and in a declarative way very similar to what you/jonas are asking
for.  

It may be worth considering two things separately here:  

a) In terms of things like robots, search engines, non-browser agents.. Are
you/jonas really hard sold on the idea that this is a significant problem? This
feels kind of similar to rdf or microdata (in this very limited sense) in that
given the right pieces (which I think the draft provides) techs like search
engines will start taking advantage of it once it is there even if they don't
now...  and they are no worse off for it than they are now where they are also
currently hopeless with the current myriad of approaches to these problems.  I
think that this alone shouldn't be a deal-breaker as it could
unnecessarily/unfairly limit the potential scope of solutions. 

b) In terms of older browsers/browsers which have important features
disabled... Is this more or less of a problem in your mind than a)?  Again, I'm
not sure that this makes it any worse than the current situation and with
evergreen browsers and the fact that it isn't worth it for many apps/sites to
have almost infinite fallbacks I'm not sure how important this appears to
potential users, but I understand that that is not your perspective... To be
honest, even leaving that aside - I can see some kind of argument for wanting
some nice declarative manner for specifying fallback content, even mid-upgrade
if your script determines that the browser is missing some important feature
which would entail the same kind of consideration.  Is it possible that if we
provided a solution for that, we might somehow be able to make it answer all of
b) - and would that be enough for you to give it (even begrudgingly maybe) your
blessing?   


Quick aside: I've said this in the past to (almost) all of you online or off,
but I am not convinced that every custom component even has an element that it
can 'extend' and gain anything worthwhile in terms of usability or anything
like that.  In fact, since they can be composed, this gets harder and harder I
think.  This argues - to me at least, that the approaches you and jonas are
talking about are very limiting in terms of what would be possible, unless
somehow we make an explicit "fallback" idea,  but I could be missing something
important.  If so, help me understand?

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

Received on Friday, 4 January 2013 17:29:35 UTC