[whatwg] Adding a src attribute to all elements

2009-11-03 Thread Curtiss Grymala
I would like to propose that a src attribute be added to the spec for
all HTML elements. The content of the file referenced in the src
attribute would then replace the contents of the element that contains
the src attribute. The src attribute would then be interpreted
differently, depending on the type of file referenced in that src
attribute.

For instance, if I create a level 1 header that looks like:
h1 src=/example.pngThis is a header/h1
The text This is a header would be replaced with the image that's
located at /example.png. However, if /example.png returns a 404 error,
the text would be displayed instead.

If, however, I create a div that looks like:
div src=/example.txtThis is some other text/div
The text content of /example.txt would replace the text This is some
other text within the div that I created. Again, though,
if /example.txt returned a 404 error, then This is some other text
would show up inside the div instead.

The contents of the file referenced in the src attribute would need to
be parsed and rendered prior to replacing the initial content of the
element. For instance, if I reference a PHP file in the src attribute, I
would expect the PHP to be parsed before it shows up in my document.

I'm not sure if this is at all feasible, but I personally think it would
be a great addition to the spec. Thank you.




Curtiss Grymala
curt...@ten-321.com




[whatwg] A call for tighter validation standards

2009-10-22 Thread Curtiss Grymala
Much of what I wanted to discuss was discussed rather elegantly within a
post from August 2009
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021725.html) 
on this mailing list, but I would like to take it a step further. Henri Sivonen 
made some very valid points within that post, and I agree with most of what he 
said.

I also wrote an open letter to the WHATWG on the HTMLCenter blog
(http://www.htmlcenter.com/blog/an-open-letter-to-whatwg/) laying out
some of my thoughts. I would like to use this message to build upon what
I wrote in that blog post, but I don't really want to rehash what I've
already said.

My main concerns about the current version of the HTML5 specs were laid
out pretty well by Henri in the mailing list message from August 2009 I
linked above. However, I wanted to reiterate the ones that concern me
and add my thoughts.

 1. Unquoted attributes
 2. Implied tags (such as leaving out a closing paragraph tag)
 3. Inconsistent use of the closing slash on empty elements

My concern with all three of these points is that they are relying on
the browser to interpret the coder's intent when rendering the elements.
The unquoted attributes and implied tags are subject to wide
interpretation by the browsers. Regarding the unquoted attributes, I
fear that new coders might not understand when and why attributes should
be quoted and will spend a lot of time wondering why their pages are not
rendering properly. For instance, imagine a new coder trying to declare
inline style definitions without quoting the style attributes. How will
a browser interpret something like:

p style=width: 500px; height: 100px;

It becomes even more dangerous in that height and width are actually
attributes of most HTML elements, so the browser will have to do quite a
bit of work to figure out what to do with these types of definitions.

The implied tags can be just as frightening. For instance (and I realize
this is not the best example, but it's the one I can think of at the
moment), what happens with the following:

HTML Version:
pThis is some paragraph text.
spanThis is some more text/span

XHTML Version:
pThis is some paragraph text./p
spanThis is some more text./span

In the XHTML version above, it's obvious that the span will be separated
from the paragraph text. However, in the HTML version, browsers will
include the span in the paragraph (unless appropriate CSS is applied to
the span).

I would like to reiterate that I am not asking the WHATWG to recommend
browsers dropping support for any older HTML specs (in fact, I am very
much in support of the browsers continuing to support all older HTML
specs and, to the best of their ability, supporting HTML from before
there were specs and recommendations).

However, what I am asking is that the WHATWG consider writing the specs
so that those older, less rigid styles of coding do not validate
according to the standard. Coders will still be free to write the code
with implied closing tags, unquoted attributes and inconsistent use of
the closing slash, but I don't believe that type of code should
validate, as it does not conform to an actual standard, rather it
conforms to exceptions to standards.

In my blog post, I likened the looser standards of HTML5 to removing
laws against driving while intoxicated. Sure, abolishing those laws
would not force anyone to drive drunk, but without any legal
ramifications for doing so, it would be much more prevalent. As with
that example, if the standards for HTML are loosened as compared to
XHTML 1 (served as text/html), coders will not feel the need to code
neatly or consistently, and we will begin to slip back into the
spaghetti code we experienced throughout the 1990s.

I appreciate you taking the time to read this message, and I hope I can
have at least a little bit of an impact on the formation of these
standards. Thank you.




Curtiss Grymala
curt...@ten-321.com