Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

> Do you have any examples of a large Web app in which they can continue to function while some or all custom elements have failed to load?

Every single one at my place of work.  I actually use polymer *heavily*, but it all falls back properly thanks to excessive use of `is=""`.  :-)

> Browsers would not be able to do this because in practice, the assistive technology looks at what's rendered to the screen (CSS box model), not DOM.

Not always, I wish though...  I've had entire hidden elements entirely read off...  >.>

> I agree with about 90% what @rniwa wrote. If i need a certain component for my current view, i dont want to show anything to the user until the component is loaded. And only in the case that the component failed to load, js is disabled or CEs arent even supported, i want to provide fallback content. But this fallback content is just very simple content like an Image or Info message in the hugh majority of cases.
> Whats the point of having reusable components when i reimplement it "the old way" anyway.

I have css at the top that hides the body, loads the javascript synchronously (if it can load at all, I bundle all JS into a single file), then a style at the bottom of the body unhides the body.  It has worked in every situation that I've been able to try so far.

> However, I am pretty sure AMP HTML doesn't load everything at once (or maybe it does, but I don't have other examples).

Really hate AMP...  >.>

> Others already mentioned screen readers I believe would ignore CSS completely.

Eh, it's random.  Sometimes they will ignore an element hidden via CSS, sometimes they don't, the "don't" ones suck, but I have to support them regardless...

> Are there (medium+ sized) React Apps that have no-JS fallbacks beyond displaying a message "Please activate JS" or a static SSR view that has almost no UX and only a tiny (non-interactive) feature set of the complete app? I personally havent seen any and tbh i wouldnt even care (and lots of "average-webworker-joe" customers wouldnt either)

And this is why I am not a fan of the react style, though in some rare cases it is useful (highly dynamic pages, like a messenger...), though I use bucklescript-tea instead of react.

> So why should webcomponents support more than these kind of fallbacks, if noone is goin to use them even in React, where it would be possible to fallback very gracefully.

Different use-cases.  React is useful for highly dynamic pages, not just displaying content (anytime I see a site that uses react to show static content get blocked very quickly...), webcomponent fallback is for when a page needs to work in all cases, which is common in, say, government for example.

> What about a form to make a selection from thousends of options empowered by a search input that is backed by an elastic search. providing such functionality without JS is just a painful UX.

And yet I have to support it, and indeed I do, I have a search bar that refines a drop-down list as you type if you have javascript, if you do not then a submit will refresh the page with the typed results.  It is not hard to do at all.

> also compare this to customelements v1:

Exactly!  Your `fallback` fails on anything old, screen readers, and a dozen dozen other things, where `is` is an 'opt-in' instead of an opt-out, thus it will work in one way or another everywhere.  As well as yours would fail hard in things like tables or templates or a few other things.

> that is not true anymore for a lot of modern screen readers. also especially blind webusers are by nature more willing to ugrade their software than your average user (this is backed by my experience from working with companys that specifically create web pages for blind users).

You've apparently not worked in government, I unfortunately have to.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/509#issuecomment-302442646