3 ms·

If typing is the problem, there's the zen coding plugin to alleviate it http://code.google.com/p/zen-coding/ http://code.google.com/p/zen-coding/ As far as en

by lhorie 16y ago

If typing is the problem, there's the zen coding plugin to alleviate it http://code.google.com/p/zen-coding/ http://code.google.com/p/zen-coding/ As far as ending tags go, HTML actually allows optional closing tags in some elements (http://www.w3.org/TR/html401/index/elements.html http://www.w3.org/TR/html401/index/elements.html) and the proposed idea of using </> would cause confusion: <ul> <li>bla </> <- what did I close here?

jacobolus 16y ago
> [...] cause confusion: [...] ← what did I close here? This was covered in TFA, except that JGC apparently thinks that having optional tags is an attempt at DWIM that’s more trouble than it’s worth: > The browser magically says: “Oh, he must have meant to close that <p> tag so I'll do it for him.” [...] Given that the tags are meant to be balanced there's no reason to force the author to figure out which tags they want to balance and force them to write it down. It adds nothing. Personally, though, I think implicit end tags are just fine, as long as they’re clearly documented and browsers have a standardized & predictable parsing approach.
- lhorie 16y ago
  >> This was covered in TFA Not exactly... he basically said "let's drop the current spec and use lisp". The thing I noticed when looking at language design though is that it's really easy to say "language X should look like Y" but overlook something that makes the whole proposal a really bad idea. Case in point: can you spot the problems on his lisp example? (hint: elements vs text nodes, required escape sequences)
  - jacobolus 16y ago
    Well, okay. What I meant was that your criticism implied that he didn’t understand/address implicit tags, while he clearly actually did, but just suggested they be dropped. I also hope his examples were more like a sketch than a careful proposal – otherwise, as you said, there’s a lot of ambiguity. Anyway, there are clear advantages and disadvantages to both models. I’m not personally convinced that either HTML or S-expressions is an especially good document format, at least not as far as a human trying to create a document is concerned, but fortunately these kinds of languages are easy enough to generate that the original source language can pretty much look like whatever someone can imagine.

by lhorie 16y ago

jacobolus 16y ago

> [...] cause confusion: [...] ← what did I close here? This was covered in TFA, except that JGC apparently thinks that having optional tags is an attempt at DWIM that’s more trouble than it’s worth: > The browser magically says: “Oh, he must have meant to close that <p> tag so I'll do it for him.” [...] Given that the tags are meant to be balanced there's no reason to force the author to figure out which tags they want to balance and force them to write it down. It adds nothing. Personally, though, I think implicit end tags are just fine, as long as they’re clearly documented and browsers have a standardized & predictable parsing approach.

lhorie 16y ago
>> This was covered in TFA Not exactly... he basically said "let's drop the current spec and use lisp". The thing I noticed when looking at language design though is that it's really easy to say "language X should look like Y" but overlook something that makes the whole proposal a really bad idea. Case in point: can you spot the problems on his lisp example? (hint: elements vs text nodes, required escape sequences)
- jacobolus 16y ago
  Well, okay. What I meant was that your criticism implied that he didn’t understand/address implicit tags, while he clearly actually did, but just suggested they be dropped. I also hope his examples were more like a sketch than a careful proposal – otherwise, as you said, there’s a lot of ambiguity. Anyway, there are clear advantages and disadvantages to both models. I’m not personally convinced that either HTML or S-expressions is an especially good document format, at least not as far as a human trying to create a document is concerned, but fortunately these kinds of languages are easy enough to generate that the original source language can pretty much look like whatever someone can imagine.