- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Jan 2013 17:29:33 +0000
- To: public-webapps-bugzilla@w3.org
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