You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not really sure anything should be done about this here, but wanted to point out that while making codepen examples for popover, i have had to turn off the inclusion of normalize.css due that style sheet's use of display: block on HTML elements like menu, article, and such.
May be worth a mention in future communication about the attribute that some of these sheets that were made for the purpose of resetting / normalizing HTML elements may actually cause issues with using new web features that these style sheets obviously could never have accounted for.
@scottaohara thanks - yeah I'm not entirely sure what to do with this issue outside of possibly raising it as a concern in the CG so that folks giving talks, etc can make sure to call this out. What specific issues were you hitting?
@gregwhitworth that the popover was shown by default because normalize was adding display block, per the old 'add display block to all the new html5 elements', to elements with the popover attribute.
This is a great point! I wonder if someone (OP, hint hint) would be willing to file an issue with the normalize.css folks about this? I guess this applies to any "reset" stylesheet framework, of which there are several.
@jh3y I wonder if you have some visibility into the folks behind those and could reach out? Or at least mention this in a post somewhere?
Hmm. I have some stylesheets where I've had to put a reset or something in place.
Perhaps this is something to make more prominent in the article/explainer? I didn't see this behavior with article. But, I tried menu and sure enough it applied display: flex. And ideally, you'd want something like:
menu:not([popover]) { display: flex; }
The problem here is that it will be very hard to cater to all cases. That normalize example is a good one though. Perhaps an aside about stylesheet resets on the article/explainer wouldn't be a bad idea here. I think we need to update the explainer anyway because of the event changes. I planned on looking at that tomorrow.
@mfreed7, @jh3y went to go file that issue today, but realized that at least latest version of normalize css (v8 - released 4 years ago) has removed this style. Checking codepen (where i encountered this issue) they are using version 5... so, I've sent them an email via their support page to request they update their version of normalize, referencing this issue for more context.
The problem here is that it will be very hard to cater to all cases. That normalize example is a good one though. Perhaps an aside about stylesheet resets on the article/explainer wouldn't be a bad idea here. I think we need to update the explainer anyway because of the event changes. I planned on looking at that tomorrow.
Thanks!
@mfreed7, @jh3y went to go file that issue today, but realized that at least latest version of normalize css (v8 - released 4 years ago) has removed this style. Checking codepen (where i encountered this issue) they are using version 5... so, I've sent them an email via their support page to request they update their version of normalize, referencing this issue for more context.
At least that's good news that the potential breakage is more limited than originally thought.
Yah. So from what I got back from codepen is that people can change the normalize version if they want. but it's defaulting to version 5 when it is used. They're looking into updating that at some point, but they are hesitant to make any changes to existing pens - which makes sense. Shrug... seems an issue that people may run into if they're unaware (as i was) to this super old version as the default. But, there is an opt out, so maybe this can just be closed, or at least, this can serve as a reminder for when this eventually comes up?
Activity
gregwhitworth commentedon Jan 3, 2023
@scottaohara thanks - yeah I'm not entirely sure what to do with this issue outside of possibly raising it as a concern in the CG so that folks giving talks, etc can make sure to call this out. What specific issues were you hitting?
scottaohara commentedon Jan 3, 2023
@gregwhitworth that the popover was shown by default because normalize was adding display block, per the old 'add display block to all the new html5 elements', to elements with the popover attribute.
mfreed7 commentedon Jan 19, 2023
This is a great point! I wonder if someone (OP, hint hint) would be willing to file an issue with the normalize.css folks about this? I guess this applies to any "reset" stylesheet framework, of which there are several.
@jh3y I wonder if you have some visibility into the folks behind those and could reach out? Or at least mention this in a post somewhere?
jh3y commentedon Jan 19, 2023
Hmm. I have some stylesheets where I've had to put a reset or something in place.
Perhaps this is something to make more prominent in the article/explainer? I didn't see this behavior with
article. But, I triedmenuand sure enough it applieddisplay: flex. And ideally, you'd want something like:The problem here is that it will be very hard to cater to all cases. That normalize example is a good one though. Perhaps an
asideabout stylesheet resets on the article/explainer wouldn't be a bad idea here. I think we need to update the explainer anyway because of the event changes. I planned on looking at that tomorrow.scottaohara commentedon Jan 20, 2023
@mfreed7, @jh3y went to go file that issue today, but realized that at least latest version of normalize css (v8 - released 4 years ago) has removed this style. Checking codepen (where i encountered this issue) they are using version 5... so, I've sent them an email via their support page to request they update their version of normalize, referencing this issue for more context.
mfreed7 commentedon Jan 23, 2023
Thanks!
At least that's good news that the potential breakage is more limited than originally thought.
scottaohara commentedon Jan 23, 2023
Yah. So from what I got back from codepen is that people can change the normalize version if they want. but it's defaulting to version 5 when it is used. They're looking into updating that at some point, but they are hesitant to make any changes to existing pens - which makes sense. Shrug... seems an issue that people may run into if they're unaware (as i was) to this super old version as the default. But, there is an opt out, so maybe this can just be closed, or at least, this can serve as a reminder for when this eventually comes up?
gregwhitworth commentedon Jan 23, 2023
@scottaohara @mfreed7 @jh3y any reason to keep this issue open?