Hacker News new | comments | show | ask | jobs | submit login

I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something?

The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.




Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future.

Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive.

Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.


You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance:

  <sidebar></sidebar>
can instead be coded as:

  <span data-sidebar></span>
or something similar.

[1] -- http://docs.angularjs.org/guide/directive


Custom elements are part of the HTML5 spec too:

http://w3c.github.io/webcomponents/spec/custom/

The only requirement is that they have a dash in the name. So while <sidebar> is not a valid HTML5 element, <a-sidebar> would be.


That's my usual way, or the class-based way for older IE.


Maybe prepend them with "an-" or something?

Yes, this is actually the recommended practice from the documentation. Built-in Angular directives are typically prefixed with `ng-`, and they suggest that other projects/developers use their own prefixes to avoid conflict.


That seems like a poor reimplementation of XML namespaces.

Why not use XHTML at that point? If XHTML ever had a clear mission statement in life it was that.

I mean I thought XHTML was a curse a few years ago when it was The Thing Every Good Designer Uses™ since it couldn't be rendered as XML in the most popular browser. But hopefully that's not as much an issue anymore. Or maybe it is. I haven't kept up with IE.


>That seems like a poor reimplementation of XML namespaces

Or you know, an adoption of only the needed part, instead of all the BS junk that comes with XML namespaces.

>Why not use XHTML at that point?

Because of all the other junk that comes with it. And because it comes from W3C.


XHTML is on the way out, I'm afraid. Angular is designed for HTML5.


Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/

When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: