Make styles optional?

[Nettsentrisk]

If you're handling styling of the summary elements on your own, there's no way to use this polyfill without it polluting your styles and requiring overriding them everywhere you intend to use your own styles.

Optimally the CSS for this package would be included separately, so you can import the styles into your stylesheet setup if you want. Either that or there should be two versions of the script, one without polyfilling styles, and one with.

An example: Bootstrap has set up their npm package so that you only get script when you import the script, and you have to import the styles separately if you want them: https://getbootstrap.com/docs/4.1/getting-started/webpack/

[javan]

The styles are only added to browsers that don't support <details> natively; hence, they're polyfilled.

For example, open data:text/html,%3Cdetails%3E%3Csummary%3Ehello%3C/summary%3E%3Cp%3Eworld%3C/p%3E%3C/details%3E in Safari or Chrome:

So you're always going to be overriding styles to customize their appearance. Either the browser's default styles or the polyfilled styles.

[Nettsentrisk]

Let me explain:

Let's say you are adding a pseudo-element to your summary elements to create a certain style, and you are styling away the default styles that the browser uses for this.

In order to override the styles that this package forces onto you when you use the script, you'll have to set display: none on the pseudo-element that is created through the package styles. However, that will remove all the custom pseudo-elements you've set up for all browsers, leading to have to override them again, which can't be done very easily due to the global nature of the included styles.

Splitting up the script and the styles like Bootstrap does lets the developer choose whether he wants the styles or not.

[javan]

In order to override the styles that this package forces onto you when you use the script, you'll have to set display: none on the pseudo-element that is created through the package styles.

You don't have to set display: none. Instead, override or reset the individual properties defined in the included styles:

details-element-polyfill/src/styles.js

Lines 8 to 16 in 5984dc6

	details > summary::before {
	content: "►";
	padding-right: 0.3rem;
	font-size: 0.6rem;
	cursor: default;
	}
	details[open] > summary::before {
	content: "▼";
	}

To remove the triangles, for example:

details > summary::before {
  content: "" !important;
}
details[open] > summary::before { 
  content: "" !important; 
} 

Splitting up the script and the styles like Bootstrap does lets the developer choose whether he wants the styles or not.

Bootstrap is not a good comparison. It's a library with optional features. This is a polyfill that replicates an HTML standard as closely as possible.

[kleinfreund]

@javan Setting content: "" doesn’t seem to be sufficient for resetting the styles in Edge. The padding is still visible and needs to be reset as well.

[javan]

Correct, that is how CSS works. I was just demonstrating how one might override some of the polyfill's styles for @Nettsentrisk, who thought it was impossible.

[Nettsentrisk]

Impossible, no. Impractical, yes. This is what I said:

there's no way to use this polyfill without it polluting your styles and requiring overriding them everywhere you intend to use your own styles

As far as I'm aware, there is nothing in any spec that states that the summary element shall be styled in the manner being done with the built-in styles in this project. Polyfilling entails providing native functionality according to some existing spec. Including some arbitrary styling of an element is not part of polyfilling.

Therefore, the styling of the element via this package should be optional, because it's actually an optional styling beyond merely polyfilling the functionality of the element.

[muan]

There is suggested styling for the element in spec. A disclosure indicator is needed and not optional; unfortunately it hasn't been implemented uniformly. See:

• Need a way to styling the disclosure triangle of the <details> (or <summary>) element whatwg/html#722
• https://www.w3.org/TR/css-counter-styles-3/#ref-for-disclosure-open
• https://bugzilla.mozilla.org/show_bug.cgi?id=1221416
• https://bugs.chromium.org/p/chromium/issues/detail?id=590014

While the exact implementation is being finalized, I think what this project currently does is reasonable and should stay.

[javan]

You also said:

In order to override the styles that this package forces onto you when you use the script, you'll have to set display: none on the pseudo-element

Which is not true so I took time out of my day to present a detailed example of why you don't have to set display: none.

Including some arbitrary styling of an element is not part of polyfilling.

They're not arbitrary by any means:

Example 1

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details

Example 2

https://www.w3.org/TR/html5/interactive-elements.html#the-details-element

Therefore, the styling of the element via this package should be optional

You've used the word should several times now, and your tone has been generally unfriendly. I've chosen not to remove the default styles from this polyfill, which I provide for free on my own time. If you're not happy with that decision, fork it and move on.

[Nettsentrisk]

As @muan has pointed out, the standards-based way of doing this is via the list-style property, not using a pseudo-element (or in the case of some Webkit browsers, the ::webkit-details-marker pseudo-element).

Introducing a pseudo-element means that you are interfering with the developer's choices/preferences to use the ::before pseudo-element for their own purposes completely unrelated to this polyfill or a "native" experience of it.

Therefore you would have to use a general style on all summary::before elements with display: none if you are not interested in this being displayed this way, which interferes with any existing summary::before styles you may have.

The arbitrary nature of the implementation is by doing it via pseudo-element, which is not based on any standard or spec, and which causes unforeseen and unneccessary problems.

If you allow people to use the style-portion of it separately, like Bootstrap does, then none of this would be an issue, because then it would be up to the developer whether or not they want to implement this non-standards based styling.

Obviously I could fork the project and do this on my own, but it would be a shame for this package to split off a lot of users simply because the author doesn't want to allow it to be used more flexibly. There are several of us now that have brought up this issue.

Why not make more people happy using your code than less? :)