Consider dropping the hyphen #161
Comments
|
Heya, thanks for opening this. This is an interesting question on a few levels. Our current design is that we'd like to keep a hyphen in the name, but not put it in the list of invalid custom element names. That makes this new HTML element, unlike all others before it, 100% polyfillable. We'd like to move away from a world where browsers get a special namespace all to themselves, which web developers can never faithfully polyfill. But, why did we divide up the namespaces in the first place? Well, because we wanted to avoid conflicts: if the browser later adds a The way we avoid this with this proposal is by requiring an opt in I hope this clarifies the thinking. We should definitely document this better; we'll leave this open to track it. I'll also note that this approach, of using a valid custom element name for a built-in element but hiding it behind an import statement, is a novel and untested one. We're going to give it a try, with this proposal and others, but it definitely needs some battle-testing and discussion. There are alternative ways to solve the same polyfillability problem that might be better: for example, we could remove the restriction that custom element names require a hyphen, and then promise to never introduce any new built-in elements unless they are guarded by an Finally I'll note that the name |
|
Thanks @domenic for the detailed response. This seems certainly like a novel approach, and I wonder if it would be worth having a separate proposal for standardizing on the mechanism for explicitly opting-in to new HTML elements? I'm not fully convinced by the dependency on Javascript to enable a particular feature in the HTML language. What will happen for browsers where Javascript is disabled? Or browsers that don't support Javascript at all? Can these still support this element? What about AMP with its tight restrictions on script tags? An alternative would be to use a meta tag inside |
|
I think in general, we're pretty sold on using JavaScript imports as a way of importing new functionality. Cf. the move from HTML imports to HTML modules. |
|
Using Javascript imports as a way of importing new Javascript functionality makes a lot of sense. Custom elements are Javascript functionality, so the move from HTML imports to HTML modules as a way to bring that Javascript functionality to the current page is reasonable. These custom elements wouldn't work without Javascript anyways. But this is a new standard HTML Element, that could be used in a purely static page. Except that page needs to become dynamic and run Javascript just for that tag to upgrade and not behave like a This has many implications that should be made explicit, and discussed, such as the ones I listed above, but you can also think of the consequences (probably both positive and negative) to CMS systems, where users can't typically inject script tags. |
|
I'm with @rubenlg on this, while yes we're going to be using Javascript everywhere under the hood to wire all of this up, the author shouldn't have to write an import statement to have access to them. I'm curious to hear what benefits you feel this will provide over auto importing when |
|
Auto-importing is not a feature web authors have access to, and I don't think we should be introducing more magic capabilities into the platform that are reserved for UA vendors (and, notably, impossible to polyfill). If we standardized something around WICG/webcomponents#782, then that might make sense. |
|
@domenic We're in agreement, I'm merely stating that we should have that in order to light this functionality up as I think that's what authors will expect. That said, having it be async is not necessarily the approach I think many authors would expect - as some pointed out in the issue you linked to. |
|
I am fully on board with wanting to have HTML evolve, so long as it is cow-path driven. On the other hand, JavaScript is at the heart of many privacy problems endemic to the Web. New elements should definitely not rely on script being enabled. Maybe there could be a way to isolate the execution of standard elements from the JavaScript execution environment of the page, especially if they are opt-in? |
A CMS could cache the rough equivalent of this PHP pseudocode when requesting user-specified HTML for the first time, invalidating it any time the end user updates the HTML: $imports = [];
$fallbacks = [];
foreach ($content->get_tags_to_polyfill() as $tag) {
$mod = STD_MODULES[$tag];
if (!isset($imports[$mod])) {
$imports[$mod] = 'import "' . $mod . '";';
}
$fallbacks[] = htmlspecialchars($tag);
}
$content->set_cached_html(
'<script type="module">'.implode($imports).'</script>' .
'<script nomodule src="'.TAGS_POLYFILL.'?t='.implode(',', $fallbacks).'"></script>' .
$content->input_html()
);You already have to parse the HTML to censor scripts server-side, so I don't find this infeasible for CMSs to also do internally. (The CMS can provide the functionality to handle this correctly, so developers don't have to.) |
|
@domenic By any chance, is there any repo dedicated towards the design side of this particular experiment of fully polyfillable HTML elements, or is it just some informal experiment/process that's mostly word-of-mouth and similar? I have a few thoughts and questions about that effort, but I feel they would likely be off-topic for this bug and more so the repo as a whole. |
|
@isiahmeadows is whatwg/html#4696 what you're looking for? |
|
@dauwhe That would be it. Thanks! |
The web components spec requires using hyphen to signal that something is a custom element as opposed to a native element. There are already a bunch of native elements with hyphens, and I think it would be worth not augmenting that list:
http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element-type
The text was updated successfully, but these errors were encountered: