headers
Andrew Fedoniouk | 1 Dec 2006 01:05
Favicon

HTML syntax: shortcuts for 'id' and 'class' attributes

While we are on the subject of discussing HTML syntax....

How about following (wild) idea?

To allow following notation (borrowed from CSS selectors):

<p.myclass>...</p> is equivalent of 
<p class="myclass">...</p> 

<p#myid>...</p> is equivalent of 
<p id="myid">...</p> 

<p.myclass1.myclass2>...</p> is equivalent of 
<p class="myclass1 myclass2">...</p> 

<p#myid.myclass1.myclass2>...</p> is equivalent of 
<p id="myid" class="myclass1 myclass2">...</p> 

It is syntax sugar of course but at least it will reduce amount of data 
needs to be sent over the wire.

Andrew Fedoniouk.
http://terrainformatica.com
Permalink | Reply | 4 comments |
headers
David Håsäther | 1 Dec 2006 01:19
Picon

Re: HTML syntax: shortcuts for 'id' and 'class' attributes

(Accidently only sent the first mail to Andrew).

On 12/1/06, Andrew Fedoniouk <news@...> wrote:
> While we are on the subject of discussing HTML syntax....
>
> How about following (wild) idea?
>
> To allow following notation (borrowed from CSS selectors):
>
> <p.myclass>...</p> is equivalent of
> <p class="myclass">...</p>
>
> <p#myid>...</p> is equivalent of
> <p id="myid">...</p>
>
> <p.myclass1.myclass2>...</p> is equivalent of
> <p class="myclass1 myclass2">...</p>
>
> <p#myid.myclass1.myclass2>...</p> is equivalent of
> <p id="myid" class="myclass1 myclass2">...</p>
>
> It is syntax sugar of course but at least it will reduce amount of data
> needs to be sent over the wire.

HTML5 is meant to be backwards compatible, so this is out of the question.

--

-- 
David Håsäther
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Fedoniouk | 1 Dec 2006 02:28
Favicon

Re: HTML syntax: shortcuts for 'id' and 'class' attributes


----- Original Message ----- 
From: "David Håsäther" <hasather@...>
To: "Andrew Fedoniouk" <news@...>
Cc: "WHAT Working Group Mailing List" <whatwg@...>
Sent: Thursday, November 30, 2006 4:19 PM
Subject: Re: [whatwg] HTML syntax: shortcuts for 'id' and 'class' attributes

| (Accidently only sent the first mail to Andrew).
|
| On 12/1/06, Andrew Fedoniouk <news@...> wrote:
| > While we are on the subject of discussing HTML syntax....
| >
| > How about following (wild) idea?
| >
| > To allow following notation (borrowed from CSS selectors):
| >
| > <p.myclass>...</p> is equivalent of
| > <p class="myclass">...</p>
| >
| > <p#myid>...</p> is equivalent of
| > <p id="myid">...</p>
| >
| > <p.myclass1.myclass2>...</p> is equivalent of
| > <p class="myclass1 myclass2">...</p>
| >
| > <p#myid.myclass1.myclass2>...</p> is equivalent of
| > <p id="myid" class="myclass1 myclass2">...</p>
| >
| > It is syntax sugar of course but at least it will reduce amount of data
(Continue reading)

Permalink | Reply | 2 comments |
headers
=?ISO-8859-1?Q?=D8istein_E._Andersen?= | 1 Dec 2006 02:44

Re: Allow trailing slash in always-empty HTML5 elements?

Trailing slashes in void elements are clearly unnecessary from a syntactic point
of view, but I think it can be argued that allowing them actually makes HTML
more internally consistent.

Current versions of HTML allow many unnecessary closing tags to be omitted
(e.g., </p>), and for authors exploiting this feature, adding trailing slashes to void
elements probably does not make much sense. Let's call this syntax I.

But current HTML also allows closing tags to be used for all non-void elements.
Authors doing this consistently will quite reasonably want to indicate closure of void elements
explicitly, which can be done by allowing something like either <img/> or <img></img>,
of which the former is probably preferable because it makes it overt that the element
is void, i.e., that it must be empty. Let's call this syntax II.

[Personally, I would like a conformance checker to issue either a warning or an
informational statement if (1) some, but not all optional closing tags are omitted,
if (2) some, but not all void elements contain a trailing slash, and perhaps even
if (3) the author does not adhere to either syntax I or syntax II. I do realise, though,
that others may want to keep conformance and consistence separate, and that such
additions to a conformance checker are unlikely to be made if important
modifications would be necessary in order to do so. This is only one example of
inconsistency that authors might want to avoid, of course.] 

Finally, not allowing trailing slashes in HTML does indeed make the format more
different from XHTML, but this does probably not imply that the distinction
between the two will be clearer or easier to grasp, which is what is really wanted.

--

-- 
Øistein E. Andersen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Fortin | 1 Dec 2006 03:15
Gravatar

Re: Allow trailing slash in always-empty HTML5 elements?

Le 30 nov. 2006 à 16:46, Sam Ruby a écrit :

> On 11/30/06, Michel Fortin <michel.fortin@...> wrote:
>
>> We can't really have a document that is both HTML5 and XHTML5 at the
>> same time if we keep the <!DOCTYPE HTML> declaration however.
>
> Why not?

It seems I was mistaken about that. I was pretty sure that it'd be a  
parse error in XML, but I now look at the [DTD construct in the XML  
spec][1] and I cannot see why. Apparently this is a valid DTD for an  
XML document where the root element is <html>:

     <!DOCTYPE html>

These wouldn't since XML is case-sensitive:

     <!DOCTYPE HTML>
     <!doctype html>

  [1]: http://www.w3.org/TR/REC-xml/#dtd

So it appears after all that if HTML allows "/>", it would be  
possible and practical to have a single document which is valid for  
both HTML and XHTML at the same time. That doesn't mean the document  
will behave in the same way in the two cases however.

I wonder if allowing "/>" in HTML couldn't, on the opposite of some  
other arguments, help authors and developers to grasp the real
(Continue reading)

Permalink | Reply | 57 comments |
headers
Ian Hickson | 1 Dec 2006 04:22
Picon

Re: Allow trailing slash in always-empty HTML5 elements?

On Tue, 28 Nov 2006, Sam Ruby wrote:
> 
> In HTML5, there are a number of elements with a content model of empty: area,
> base, br, col, command, embed, hr, img, link, meta, and param.
> 
> If HTML5 were changed so that these elements -- and these elements alone -- 
> permitted an optional trailing slash character, what percentage of the web
> would be parsed differently?

0%. Allowing or disallowing something is completely orthogonal to how it 
is parsed.

> The basis for my question is the observation that the web browsers that 
> I am familiar with apparently already operate in this fashion, this 
> usage seems to have crept into quite a number of diverse places

Browsers don't do any sort of conformance reporting for HTML parsing, so 
they can't actually be said to be allowing it or disallowing it. As far as 
parsing goes, all browsers, as well as the HTML5 parsing specification, 
handle bogus trailing / characters in tags by ignoring them.

> As a side benefit of this change, I believe that I could modify my weblog to
> be simultaneously both HTML5 and XHTML5 compliant

Since the namespace declaration is required in XML and disallowed in HTML, 
this is not possible. In addition, while you may be right that a tiny 
subset of XML might be equivalent to a tiny subset of HTML, it is not, and 
will never be, generally true that you can take an arbitrary HTML5 
document and treat it as XML. HTML5 has very detailed parsing rules (at 
least as detailed as XML, and arguably more detailed, since the HTML
(Continue reading)

Permalink | Reply | 28 comments |
headers
Lachlan Hunt | 1 Dec 2006 06:02
Picon

Re: Allow trailing slash in always-empty HTML5 elements?

Mike Schinkel wrote:
> 1.) I read the FAQ http://blog.whatwg.org/faq/ and it seemed to imply that 
> HTML 5 and XHTML where not at odds with each other?  Did I misread that, 
> because from comments on this thread I get the impression that might not be 
> the case.
> 
> 2.) A similar question, but is the goal for HTML5 and XHTML to slowly
> converge, or is the goal for them to diverage?

This issue was explained in detail in this recent blog entry.

http://blog.whatwg.org/html-vs-xhtml

--

-- 
Lachlan Hunt
http://lachy.id.au/
Permalink | Reply | 1 comment |
headers
Andrew Fedoniouk | 1 Dec 2006 06:18
Favicon

Re: HTML syntax: shortcuts for 'id' and 'class' attributes


----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky@...>
To: "Andrew Fedoniouk" <news@...>
Sent: Thursday, November 30, 2006 9:03 PM
Subject: Re: [whatwg] HTML syntax: shortcuts for 'id' and 'class' attributes

> [off list, since it's totally the wrong list]

Oops, didn't realize that, terribly sorry.

>
> Andrew Fedoniouk wrote:
>> 1) HTML5 is backward compatible with HTML4 so any HTML5 aware UA can read 
>> HTML4 files
>> without any additional setup. That implies HTML4 is a subset of HTML5.
>
> HTML4 is not a subset of HTML5.  But HTML4 that's actually used on the web 
> is a subset of HTML5, generally speaking.  Thus any HTML5 aware UA can 
> render the HTML4 that's used on the web.
>
>> 2) Any HTML4 aware UA can render HTML5.  That is possible only if HTML5 
>> is exactly HTML4 or its subset (but not superset).
>
> HTML5 is not a subset of HTML4.  But it's designed in such a way that it 
> takes advantage of the extensibility features of HTML4.  Thus an HTML4 UA 
> can render an HTML5 page reasonably, though possibly not as well as an 
> HTML5 UA.
>
> The change you suggest would mean that HTML5 and HTML4 UAs would need
(Continue reading)

Permalink | Reply | 7 comments |
headers
Boris Zbarsky | 1 Dec 2006 06:26
Picon
Favicon

Re: HTML syntax: shortcuts for 'id' and 'class' attributes

Andrew Fedoniouk wrote:
> So if  HTML5 will allow following:
> 
> <p.myclass> ... </p>
> together with its full and equivalent form
> <p class="myclass"> ... </p>
> 
> then this will be backward compatible solution as
> HTML5UA will understand both forms - classic and simplified.
> Am I right?

No, because an HTML4 UA will not render that in any sort of reasonable way (for 
example, in an HTML4 UA the "p.myclass" tag will never be closed).

-Boris
Permalink | Reply | 6 comments |
headers
Andrew Fedoniouk | 1 Dec 2006 06:35
Favicon

Re: HTML syntax: shortcuts for 'id' and 'class' attributes


----- Original Message ----- 
From: "J. King" <jking@...>
To: "Andrew Fedoniouk" <news@...>
Cc: "www-html" <www-html@...>
Sent: Thursday, November 30, 2006 9:22 PM
Subject: Re: [whatwg] HTML syntax: shortcuts for 'id' and 'class' attributes

> On Thu, 30 Nov 2006 23:46:13 -0500, Andrew Fedoniouk 
> <news@...> wrote:
>
>> Ian, what does this "backward compatibility" mean?
>
> I can't speak for what Hixie considers backwards compatible, but I can 
> tell you why a construct should as that which you're suggesting is not 
> backwards compatible: A start tag such as <p.myclass> would produce a 
> "p.myclass" element, not a "p" element as one would want to have.  This is 
> true for every element type, so any document that used this construct in a 
> majority or (horror of horrors) all of its element start-tags would have a 
> document cmnposed of elements entirely unknown to an HTML4 UA.  This is 
> unacceptable, especially considering the nominal gain.
>

So in your interpretation backward compatibility of HTML5 means that
HTML5 must be a subset of HTML4. That is not general intention I beleive.

I understand motivation to keep HTML5 as close as possible to HTML4 (but not 
to XHTML?)
thus to have reasonable, say, interoperability. Thus I think statement 
"backward compatibility" needs to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane