Hacker News new | ask | show | jobs
by IgorPartola 4224 days ago
Some good ideas here but some terrible ones as well. First, <html:whatever> is terrible. We don't need namespaces in HTML (or in XML for that matter, but that's a different story). <media type="image"> would be sufficient. Even better, something like this:

    <media type="image">
        <src href="/foo.png">
        <src href="/foo-2x.png" type="high-definition">
    </media>
I do like the idea of not having generic <div>'s everywhere. You can already do this with, for example, Angular. Basically, aside from the pre-defined elements (div, span, input, etc.) I want to just use whatever element I choose myself. I should then be able to style it how I want, and by default it can be, let's say, a borderless, 0 margin, 0 padding, transparent, block element. That way I can use add <wrapper> and style it how I want. Saves keystrokes. This gets me into trouble if later browsers decide to actually support <wrapper> with different semantics than I intended, but I am sure we could work around this somehow without resorting to <html:wrapper> namespacing.

Lastly, I really would love to be able to define element behavior. I want to say that <calendar> is a link, until you click on it, then it opens a calendar, and fires such and such events, etc. Basically, instead of adding a script tag to the base template that defines how $('.calendar') should work, I want to define it globally, a la Angular's directives, then have this happen for the entire site. If the browser allowed me to have finer grained control over user input (exact keystrokes, position of cursor, etc.), I could then re-create <input type="text">! You might say "well, we already have that, the browser does it", but the beauty of doing it yourself is that you can define more complex rules for it than just "type in text". You could, for example, easily define the format of it without having to resort to ugly hacks (think a mm/dd/yyyy type input, or an insurance subscriber ID with a very specific format).

5 comments

You just gave the exact definition of web components!

https://www.polymer-project.org/platform/custom-elements.htm...

Came here to drop a link to web components ;) imho, empowering devs to define elements & their behavior is better than defining a standard set of elements & their behavior.
Sweet sweetness!
I am aware of <picture>, but it's a bit too narrow I think. The srcset functionality is really what I want, but there's also the other aspect of this: the ability to specify content-type.
We might need namespaces for webcomponents purposes probably
What's wrong with namespaces in your opinion?
Who the heck wants to type <html: before every single command? Waste of programmer's time, hard drive storage and bandwidth.
Nobody, but that's not a problem with namespaces. Just a problem that they didn't specify a default.

Treat them like namespaces aka packages aka modules in programming languages and I don't see a downside. Import what you need, allowing defaults. You're able to override terms if you really need to with stacked imports. You're able to use conflicting terms by specifying the namespace. You're able to alias namespaces to convenient short-hand. i.e.:

  <acme:video>
    <src>https://blah</src>
  </acme:video>
Yes writing "html:" explicitly everywhere seems pretty silly. When the domain's primary purpose is writing HTML, that should obviously be the default/root namespace.

But adding support for alternatives on top of that...? Not seeing the evil there.

You don't have to. You can give a value for the root namespace instead.

Namespaces are needed for embedding things like SVG, MathML, etc. in HTML or XML documents.

> We don't need namespaces in HTML (or in XML for that matter, but that's a different story).

Bzzt, wrong. How would you propose we allow other document types to be embedded in HTML (like SVG)? Just hope the tag names never collide?

The HTML5 way is to use specialized HTML tags, where everything inside is treated as the other language:

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/svg

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

Yes, this is less flexible than XML namespaces. You couldn't do something like XLinks.

I'm not the OP, but 'Bzzt, wrong' is rude, and not how people communicate on HN.

A default namespace of 'html', and explicit namespaces for is reasonable. But <html:a> instead of <a> is ridiculous and few people who currently create content for the web will ever use it.