Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This has issues:

    <list>
        <hstack spacing=s>
            <div class="icon"></div>
            <text>Westminster</text>
            <spacer></spacer>
            <text>0.5 miles</text>
        </hstack>
        ....
It is more complex then it needs to be, it puts the styling into into the html, it kills all semantic meaning and pollutes the global namespace of element names.

It should be:

    <my-cities>
        <my-city>
            <city-name>Westminster</city-name>
            <city-distance>0.5 miles</city-distance>
        </my-city>
        ....
And then simply style the custom attributes to your liking via css. If these "primitives" would use classnames instead of element names, their styles could be added like this:

    <my-cities class=pylon-list>
        <my-city class=pylon-hstack>
            <city-name>Westminster</city-name>
            <city-distance>0.5 miles</city-distance>
        </my-city>
        ....



I remember playing around with XSL years ago, it kind of blew my mind that more people weren't using it. The bandwidth savings seemed immense. But then I started to run into edge cases, and realised that gzip covered most of the bandwidth difference anyway... but I still maintain it's a super cool idea.


CSS is why we can’t have nice and easy rich UI things in web dev world. And so I downvote you...


Are those custom elements just divs by default or do you need to define them somewhere?


Technically, they should be defined:

https://html.spec.whatwg.org/multipage/custom-elements.html#...

Browsers usually treat undefined nonstandard elements as span-like (flow elements), not div-like (block elements) by default.


They are not divs. They are whatever you call them. If you mean "Are they styled like divs by default?" then also no. Divs are block elements by default while custom elements are inline elements by default.


Modern browsers indeed treat unknown elements as equivalent to divs, but it's officially undefined behavior, up to implementation.


And herein lies the flaw of custom elements: that they don't use a declarative mechanism for exposing their presence in HTML to browsers. Instead, they must be declared by subclassing from built-in element representation classes (using ES6+ class syntax which nobody seems to be using anyway). Now the browser must 1. have JavaScript 2. have JavaScript enabled 3. synchronously execute the subclassing/registration script code text before proceeding with parsing (which browsers do anyway, but at least didn't have to in order to even parse HTML as intended).

Not only that: content of custom elements is treated as fallback content (taken when a particular custom element is not available). However, that content is still subject to HTML parsing and tag omission rules, and tag omission is contextually dependent on the parent element's content model (which a custom element doesn't have since there's no way to register such using the JavaScript API).

There was (?) even the sacked mechanism of "customized built-in elements" which would allow authors to define custom attributes and behaviours for standard HTML elements. Except it doesn't work like that with HTML's enumerated attributes such as `selected` which can have shortforms like `<div selected>` where `selected` is the attribute value not the attribute name, requiring the values of all enumerated attributes be unique among all attributes in a DTD (as in SGML) or at least on a given element.

Sometimes I wonder why the HTML spec authors just had to make every blunder imaginable when there's a very rich theory of formal language and markup languages (eg. SGML and others) dealing exactly with these kind of problems.


Just tried in firefox and as mentioned above they are not block elements but inline:

    <foo>foo</foo>
    <bar>bar</bar>
    <div>div1</div>
    <div>div2</div>
Results in:

    foo bar
    div1
    div2


You're right, they are indeed considered inline elements, not blocks. My bad.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: