Re: Identifying end tags

At 11:05 AM +0200 6/23/06, Frank Hellenkamp wrote:
>hi,
>
>>  Working with nested tables, div tags and other elements may cause
>>  problems when combining code and especially when there will be
>>  different levels of nesting. It's not always easy to keep track of
>>  how many div's to end at the end of the local code and there is a
>>  potential risk of making problems for the framing code. Because of
>>  this I would like to know if there is or could be made an attribute
>>  used by programmers to keep track of the tags. The easiest part would
>>  be to use the id/class attribute also at ending the tag, but I am not
>>  sure whether this would confuse some browsers. I have used comments
>>  but they have a tendency to separate from the tag after a while, and
>>  having too many comments after each other also seems to make problems
>>  for some browsers.
>
>http://en.wikipedia.org/wiki/Redundancy
>
>if you code anything, it is better to avoid redundancy.

That is the conventional wisdom.

On the other hand, if an information tuple is going to enter
the user interface, it is best to afford redundancy.

Web media live in a demi-monde where they have some
performance pressures in both directions.

In the present case, as it bears on end tags in HTML, the CW is
probably right that HTML belongs in XML; and the extreme
simplicity of well-formedness in XML means that the tool
should track this for you by syntactic pattern, not by
data values.

On the other hand, there have got to be some applications
out there where tag soup is the natural grammar approach.
Real-time data capture, for example.

If you are going to venture into tag-soup applications based
on some YML starting point, then sure, end-tags will require
IDs.  They will probably contain nothing but IDs, and start
tags (not empty tags) will requiire IDs so they can be matched.

But don't try to take HTML there.  The [parse] trees are too
deeply rooted in this forest.

Al

Al


>it makes no
>sense to double information/functions that are already written at
>another place.
>
>we should strive for the goal to simplify things, not to complicate them.
>yes, there is some reduncy in xml, like in start and end tags, and yes,
>it is to make code more human readable. xml could have been defined as
>the following without loosing functionality:
>
><node>
>     <child>content 1</>
>     <child>content 2</>
></>
>
>>  Even though using id/class would be the best, making it easy to
>>  identify both id's and classes with potentially identical names, I
>>  guess it may be confusing for both browser and programmers. One
>>  solution would be to add e for ending to the attribute. Then it
>>  should be a new attribute that hopefully doesn't trigger any action
>>  in any browser, and it also helps programmers to see that it is an
>>  end-tag and not a new div of the same ID.
>>
>>  <div id="design"> <div id="content"> <div id="maincontent"> <div
>>  class="related"> Content </div eclass="related"> </div
>>  eid="maincontent"> </div eid="content"> </div eid="design">
>>
>>  These are just some random thoughts from someone trying to make neat
>>  and readable code. I believe you have the knowledge both to
>>  understand my problems and to find the best way to solve this.
>
>find your own approach to structure your documents by intending and
>commenting, as the other posters said.
>
>i for example use vi as an editor, indent my code and use vi's manual
>folding-capabilities through comments. e.g.:
>
><!-- {{{ navigation -->
><div class="nav_main">
>     <ul>
>         <li>point 1</li>
>         <li>point 2</li>
>     </ul>
></div>
><!-- }}} -->
><!-- {{{ content -->
><div class="content">
>     <h1>headline 1</h1>
>     <p>text</p>
></div>
><!-- }}} -->
>
>
>but that depends on your editor and the team you are working with.
>
>
>greetings,
>
>frank
>
>--
>frank hellenkamp | interface designer
>jonas.info@gmx.net | mail
>+49.30.49 78 20 70 | tel
>+49.173.70 55 781 | mbl
>+49.12120.243 912 | fax
>
>
>
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: OpenPGP digital signature
>Content-Disposition: attachment; filename="signature.asc"
>
>Attachment converted: Macintosh HD:signature 336.asc (    /    ) (001177FD)

Received on Friday, 23 June 2006 18:51:47 UTC