[Bug]: Components do not work on iOS
Closed this issue · 15 comments
Contact Details
No response
What happened?
Constructed style sheets do not work for iOS, possibly add a statement to check for support and if not render different version of web component? @annoyingmouse
What type of browser are you seeing the problem on?
Safari
Code to produce this issue.
No response
There's a polyfill for constructed style sheets - I'll add it to demo.html - I don't have access to a Mac, though, so I think you'll have to check it @MarketingPip.
PR made @MarketingPip - wasn't there another repo you wanted me to look at?
@annoyingmouse whoops I replied to wrong place!
Check your PR for my other comments, but this worked as a fix tho - I think it's something to do with polyfill (don't quote me, but the border get's messed up on dark theme) I will attach screenshots later as device just died.
@annoyingmouse reviewing somethings - wondering if we should be using Lit Component (I do believe it provides support out of the box for all needed polyfills for browsers) as well it does provide Shadow Parts which allow users to apply their own CSS if needed to the element. We could possibly as well add a feature for each element down the HTML dom - to increment a count for ID's to attach if this is not a feature already (so apply style's for each element)
@MarketingPip - I understand the attraction of using a library, but I'm not overly keen - adding a polyfill allows us to remove it in the future once iOS has caught up with the standard; in the meantime, we have to learn another library, and that comes with all sorts of pain points and extras which we might not need. It just seems less pure to me...
@annoyingmouse that I completely understand. Tho I was watching a talk from Google regarding custom components and it seems the current approach is not ideal to standards (based on what I was listening too). And Polymer / Lit component's seem to be the standard as of today. I would assume they have a built in end point for connecting to something similar or even the exact link provided to the poly fill site API end point as linked earlier. That provide's universal support with automatic testing for the required poly-fills based on device specification.
Another thing too we still need to address is the problems with content not being loaded properly (async problem).
Leaving this here for reference - Fetch Web Component Example
I will try to get to this if you don't in the meantime - tho I would like your input on the Lit components etc. As I am not over familiarly myself. (Hoping you can give some more thought & research, and base your new answer off that)
One other thing too - I forgot to mention this awhile ago. The current name for this project. Already exists. I am hoping you can suggest another suitable name for this project - as I feel you should have some input on the new name. 😄
@MarketingPip - I'm so reticent to go back to using frameworks to generate Native Web Components you wouldn't believe. I've used Polymer in the past, and I can't say it was an enjoyable experience; vanilla HTML, CSS and JS are more straightforward and cleaner. You can see what's happening, and no ugly bundling is involved. Just import the component, and away you go. Of course, you're somewhat reliant on the browsers keeping up to speed with the specification (Safari seems to be the new IE these days), but as they catch up, you can remove the polyfills.
I liked the example you posted, but we're using fetch already and within async-await, too - I'm a little confused about what you're getting at. If things aren't returned from the server, we're already displaying an error (not easy to test, TBH). The example you used uses observed attributes; I'm unsure if we need to in this case. It might be handy if we needed to change the element after it had been instantiated, but that doesn't seem to be a use case we'll need to consider (famous last words, them).
In terms of names, then media-card?
@MarketingPip - I'm so reticent to go back to using frameworks to generate Native Web Components you wouldn't believe. I've used Polymer in the past, and I can't say it was an enjoyable experience; vanilla HTML, CSS and JS are more straightforward and cleaner. You can see what's happening, and no ugly bundling is involved. Just import the component, and away you go. Of course, you're somewhat reliant on the browsers keeping up to speed with the specification (Safari seems to be the new IE these days), but as they catch up, you can remove the polyfills.
I liked the example you posted, but we're using fetch already and within async-await, too - I'm a little confused about what you're getting at. If things aren't returned from the server, we're already displaying an error (not easy to test, TBH). The example you used uses observed attributes; I'm unsure if we need to in this case. It might be handy if we needed to change the element after it had been instantiated, but that doesn't seem to be a use case we'll need to consider (famous last words, them).
In terms of names, then media-card?
To be honest - you will have more experience on Web Components than me. So I am letting you make the call on it.
The problem with the fetch / await - is sometimes valid queries. Don't provide all the info back. Sometimes a image or images will be missing but text will be there. Or sometimes just the card get's stuck in loading state and page needs refreshed for elements be loaded.
As for the name media-card I do believe it is taken. Correct me if wrong!
Ah, cool - so we just need to check to see if the correct data is returned; if not, show nothing?
Ah, cool - so we just need to check to see if the correct data is returned; if not, show nothing?
Nope - again look at the example above posted. We just need to wait till content is FULLY loaded then apply changes. If you try the demo page (unless you have amazingly fast internet) you should see what I mean. Open all the cards up (all of them have correct data besides the error cards, obviously) and see if all content loaded properly. And if not, refresh again till it does.
Notice in the example above, how they use and attribute for observing + True and False statements for loading events.
The earlier version I had set up - had a properly loading state handler too. (That waited till all content was returned & loaded then populated the element)
Hey @annoyingmouse
Hope all is well! Apologizes for not being active on this, bouncing around on some things!
Still going to be adding you to another project here soon to see if you are interested!
As well we still need to address adding the pollyfill to the document body head plus address the image load issue which is caused by (my bad too - I was wrong earlier on this)
429 status code (too many requests sent at once)
which we will need to send the request again till fulfilled with an await again.
As for final decision on name > media-card it is then? 👍
Was also hoping if you have experience with publishing packages to NPM, WebComponents etc. You can help guide or do this (as I am not familiar myself).
Hoping you have a great weekend in advanced!
@annoyingmouse - don't mind this comment. Not saying we will use it here. But possibly if we collaborate on something else or maybe want to change / make some improvements here etc.
Using this code we could allow users to bring their own styles etc. + make the script smaller than needed.
const linkElem = document.createElement('link');
linkElem.setAttribute('rel', 'stylesheet');
linkElem.setAttribute('href', 'style.css');
this.appendChild(linkElem);
Sorry, I've been poorly for the past week or two, likely to be back up and running later this week.
Sorry, I've been poorly for the past week or two, likely to be back up and running later this week.
No need for sorry at all! Hoping all is well & if feeling sick (by the sounds of it) hoping you feel better soon! 🤞
#6 addresses the fix for this issue. Closing this issue.