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

XML is so awesome for UI layouts. I had a thesis that I worked on that was basically a subset of HTML (check the SMIL specification for something similar, albeit a bit more complicated, SMIL used to be a W3C recommendation).

It was so easy to understand that every person who was able to use a computer would pick it up quickly. This was not the case for HTML, my guess is because there are a ton of HTML tags and that can be overwhelming for a certain type of audience, whereas here there are at most 10 tags to learn.

The framework I'm talking about still exist, it's called XIMPEL [1] (sadly SMIL kind of died). It may seem like a weird thing, but IMO it's the only open-source framework that has an intuitive way to make non-linear storytelling easy on the web easy. People can kind of hack a choose your own adventure media story with YouTube, but XIMPEL really is so much better at it because it's actually made for that purpose. And the biggest reason why XIMPEL is simpel because it uses XML as its template language.

People just see the tags as lego blocks and build non-linear media essays, stories or even small (media-focused) games with it.

[1] http://www.ximpel.net/




As someone who has only used html (as in, no other xml-based UI), I'm really curious why it's necessary to even define the tags at all.

Why not allow authors to define their own names? Like

  <SomeWrapper>
    <SomeChild />
  </SomeWrapper>
Then internal functionality can be attached to each element via attributes, like how aria roles work.



Yep, to some degree. Though what I would love in an xml-based UI description language is the ability to opt into default system behaviors, while maintaining the ability to use whatever semantic naming convention that fits my application.

I wrote this code in another comment, but imagine if you could hook functionality to an element via defined attributes. With custom elements, you have to add the functionality via a script, and they aren't system functions (from what I can remember, I may be wrong).

  <LabelList list>
    <LabelItem label listItem>
    </LabelItem>
  </LabelList>
In the above code:

- the LabelList element hooks into the systems "list" behavior

- the LabelItem element hooks into the systems "label" behavior

- the LabelItem element hooks into the systems "listItem" behavior


Maybe the is="" attribute gets you partway there?

    <ul is="label-list">
        <li is="list-item">foo</li>
    </ul>
EDIT: google's documentation: https://developers.google.com/web/fundamentals/web-component...


The tags are defined so that there is reasonable default behavior. For example <label> is used to label a form field. Clicking the label focuses the form field.


Would be interesting though to opt in to those behaviors. So something like

  <MySemanticLabel label>
  </MySemanticLabel>
Then you could mix and match functionalities. So if you have a list of labels, you could do the following:

  <LabelList>
    <LabelItem label listItem>
    </LabelItem>
  </LabelList>


You do opt into them, by using label. if you want an element with no behavior, that's what div and span are for.


Right, but this offers two benefits: (1) semantic naming, and (2) composed functionality. So for example, if you wanted an element that exposes label behavior and list-item behavior, you could do that. With html, you have to use 2 elements:

  <li>
    <label>
  </li>


Yes, this is a major flaw of HTML, it is very specific about where certain elements can and cannot be, so you can't really even design a solution like the above.


Congrats on re-inventing frontend web development, I heard Facebook's hiring. This is one of the reasons people use frontend frameworks (besides state management).


Why the hostility? Should we not be open to exploring alternate ideas?


I should add that I'm not literally saying that we should do this. I assume smarter people than me have thought this through, and that there are good reasons why my proposal would be a bad idea. I'd be interested to know what those reasons are.


I am not intentionally being hostile, just pointing out that your stated deficiency is the one of the reasons why people migrated to component-style frameworks. It's an affirmation of your comment's validity not a criticism.


> It was so easy to understand that every person who was able to use a computer would pick it up quickly.

I find this hard to believe. I know many people who use computers but are not IT professionals or even hobbyists. Without an easy to use GUI they can't accomplish much. I couldn't imagine them picking up anything to do with XML.

If you scope it down to UI developers you're taking less than 1% of people. Far from everyone. Even if you scope it down to IT people it's less than 1% of people.


There’s the always forgotten type of computer users: those who use computers for productivity. People who need to achieve some business goal and they have the energy to learn.

Take for instance insane Excel spreadsheets glued with VBA powering entire businesses, built by accountants and other professionals.


It’s not that they can’t. They’ve just been told they can’t.

I’ve been told that clerks at bell labs were using troff because they were told they weren’t programming and I think GUIs have the same opposite effect.




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

Search: