W3C home > Mailing lists > Public > public-html-comments@w3.org > April 2010

Re: HTML 5

From: Eduard Pascual <herenvardo@gmail.com>
Date: Wed, 7 Apr 2010 03:35:06 +0200
Message-ID: <v2u6ea53251004061835mf85449fx4d03bf322499eec@mail.gmail.com>
To: art@artspad.net
Cc: public-html-comments@w3.org
On Wed, Apr 7, 2010 at 2:10 AM, Arthur Clifford <art@artspad.net> wrote:
> If this is something that would be for code added more programmatically
IMO, that's the least important use-case: as far as I know, most
programming/scripting languages used on the web (both client- and
server- side) have some facility that turns the escaping taskt into
something trivial (like PHP's htmlspecialchars() function). Even when
such a facility is not available, the task is quite simple with raw
text-based replacing utilities (just remember to do "&"=>"&amp;"
first, so you don't re-escape the &'s that are inserted as part of the
other escapes).

The CDATA approach is a more general solution.

> what
> about something as simple as a content length attribute on the <code> or
> <pre> tag that would allow you to specify how many bytes of data are between
> the beginning and close tag?
This could easily become more painful than actually escaping the
content if you ever need to manually edit it; so you are reducing the
use-case even further to only those cases where the content is only
handled programatically. Not a very good "solution" if it only solves
a probably small fraction of the problems.

> Then you wouldn't need to worry about special
> characters at all. The User agent would read in x number of characters,
> would know the next thing it should hit is </ and if it doesn't then it can
> throw a validation error.
Then a single byte is lost due to a bad connection and, instead of
just missing a character, the whole page breaks miserably. This
doesn't suit very well in HTML5's "make sure even the craziest
tag-soup renders as close to the author's intent as possible"
philosophy. An UA could try to play smart on these cases, but it risks
to messing things up. What about if the lost byte was part of the
length attribute? Part of the snippet would be parsed as actual page
code, which leads to injection issues again (it's not an intentional
attack, but code being injected by pure randomness on a browser isn't
something vendors will be happy to implement into their UAs).

> The tags could also have a mime attribute so that
> the user agent when rendering code/preformatted text could color code
> syntax. With that W3 could work toward a code hinting standard and CSS for
> code hinting for HTML6.
While I think this is interesting, it happens to be entirely unrelated
with the problem/use-case being discussed and with the potential
solution you proposed.
I would invite you to branch it to a new thread, but the discussion
would essentially boil down to the fact that, on HTML's part, syntax
highlighting could already be applied with data-* attributes plus CSS
attribute selectors; so there is no point on adding further hooks for
as long as CSS doesn't provide anything for syntax highlighting. If
you still want to discuss this, then go ahead and start a new thread
on the topic. (From my own experience, I can assure you that trying to
discuss two separate topics on the same thread can easily become
nearly insane).

> I've never been fond of the cdata tag syntax
If there is any technical issue with the syntax itself (your personal
dislike may be an issue, but if it's "personal" then it's not
"technical"), HTML5 could define a different syntax for the same task
(after all, <![CDATA[ ... ]]> is not part of HTML, it's only part of
XML, that's why it's readily available for XHTML). From the top of my
head, things like "<< ... >>", "<[[ ... ]]>", "<! ... !>" could work
(actually, the last would quite clash with HTML's legacy inheritance
from SGML, such as the <!-- --> comment syntax; but these are just
examples).

> and have felt that xml elements
> should have a contentLength attribute.
If you have use-cases with specific requirements that are addressed by
such a feature, go ahead and start a new thread to discuss the idea.
If you can't materialize that "feeling", however, I wouldn't put much
hopes on it being taken into account by the editor.

>
> Of course I also think there should be a BEXML (Binary Enabled XML) standard
> that allows traditional XML markup with the addition of a BData tag that
> includes a content length attribute. In thinking about that, it dawned on me
> that you could have data with any characters you want with the combination
> of content length and mime type.
That's another feature suggestion without a hint on the use-cases or
requirements. Same comments as above. However, that one sounds
interesting; so if you have use-cases to warrant it some discussion be
assured I'm going to be closely following the topic :P

> But I digress. Anything read in for code or pre text should be treated as
> read and display with no processing. It could be read in and displayed as
> text, but it WOULD be nice not to have to worry about escaping characters
> when saving or returning data. Also, if someone put php or other server-side
> code in that didn't result in output that is the same length after the php
> processing then the content length would be wrong and the page would not, or
> should not, load correctly.
I already mentioned it on my reply to the OP, but the key issue here
is: if you ignore the markup while reading the contents of a given
element, how do you know where the element is? If you are watching
only for the specific "</code>" tag, how do you differentiate that one
from a pair "<code> ... </code>" within the snippet?
>
> Art
>
> Arthur Clifford
Received on Wednesday, 7 April 2010 01:35:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:02 GMT