Re: Alternate syntax for defining class attribute

Hi,

Thanks for your thoughts on this. Some notes below:

Firstly, I’m not sure the syntax is valid SGML or XML – the two
> serializations that HTML5 supports (I’m assuming the “HTML” serialization is
> based upon SGML, like HTML 4 was).


HTML5 is no longer a formulation of SGML.[1][2] Although the language has
since been changed, an editor's draft from last year[3] summed things up
well I thought:

The HTML syntax is loosely based upon the older, though very widely used
> syntax from HTML 4.01. Although it is inspired by its SGML origins, in
> practice, it really only shares minor syntactic similarities. This features
> a range of shorthand syntaxes, designed to make hand coding more convenient,
> such as allowing the omission of some optional tags and attribute values.
> Authors are free to choose whether or not they wish to take advantage of
> these shorthand features based upon their own personal preferences.


I'm fine with this new syntax not being valid in XHTML, with it being
another of those "...shorthand syntaxes, designed to make hand coding more
convenient." There are already substantial differences between the two
syntaxes. Probably one of the most relevant is that XML requires attributes
to be in quotes[4], HTML does not.[5] That's a very similar parsing
difference; but there are several others.

Secondly, there would be a significant problem with
> backwards-compatibility...I know of many institutions, including my own
> employer, that still has IE6 on the desktop).


Oh, you don't have to tell me about IE6. :-) I'm constantly running into
people thinking they can disregard IE6 on a publicly-facing website, and
constantly having to point out the inconvenient truth of IE6's ~18% market
share.

That said, I think the realities are changing. Microsoft (hi, guys!) is much
more engaged in moving forward with the browser than they have been in ten
years, being much more engaged and proactive, and the other big browsers are
very engaged and proactive as well. But as I said I think in my original,
original proposal (and I can't stress this enough): It's a case of author
beware. You don't use this syntax unless you know your target browser
supports it. Just like CSS's attribute selectors not too long ago (speaking
of IE6). Just like the `Array#indexOf` method of ECMAScript 5th edition.

Thirdly, there’s the mixing of semantics and presentation...


I'm not following you there -- how is this any more mixing semantics and
presentation than the class attribute itself? -- but I think the root of the
confusion or disagreement is this: I'm not suggesting that we change the tag
names to *include* the class. A span is a span is a span, a section is a
section is a section. I'm suggesting we allow the class to be specified (*
after* and not as a part of) the tag name, with an alternate syntax. (More
below.)

Finally, a further thought on tag names: the element’s start and end tags
> are, I believe, required to have the same name.


In <span.nifty>foo</span>, the element name is span (or, canonically, SPAN)
not span.nifty.

The tag’s name (which, as far as I understand, is every valid identifier
> character up to the first whitespace, or the end of the tag, whichever comes
> first)...


Valid characters for a tag name are A-Z, a-z, and 0-9.[6] The dot signifies
the end of the tag name. This is not a change, although it may be a change
for implementations. What *would* be a change required by this proposal is
to add to the rules in section  8.1.2.1.[7] Currently a tag name can only
have the characters I mentioned before, but is required to be terminated
with one of two things: a space, or a >. I'm saying make it three things.

A good way to look at this conceptually is:

* Allow tag names to be terminated with the dot
* Allow the dot as an alias to class
* Conflate multiple class attributes on an element

Small changes, and yes some implementations will take a while to do them
(caveat author!), but this is a long game.

[1] http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html
[2] http://www.w3.org/TR/html5/syntax.html#parsing
[3] http://dev.w3.org/html5/html-author/#syntactic-overview
[4] http://www.w3.org/TR/xml/#NT-AttValue
[5] http://www.w3.org/TR/html5/syntax.html#unquoted
[6] http://www.w3.org/TR/html5/syntax.html#syntax-tag-name
[7] http://www.w3.org/TR/html5/syntax.html#syntax-start-tag

Regards,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com


On 9 April 2010 22:05, Musgrove, Jason L <J.L.Musgrove2@wlv.ac.uk> wrote:

>  I cannot see significant value in this proposal; having written a
> considerable number of HTML documents and web applications, I cannot say I
> have seen the class attribute as a problem. However, even if I did see it a
> problem, this particular solution does, I believe, have a number of issues:
>
>
>
> Firstly, I’m not sure the syntax is valid SGML or XML – the two
> serializations that HTML5 supports (I’m assuming the “HTML” serialization is
> based upon SGML, like HTML 4 was).
>
>
>
> Secondly, there would be a significant problem with
> backwards-compatibility. I’ve just tried using one of these “hybrid” tags in
> Firefox 3.6, and IE8 – neither of them recognised “<h1.test>” as a “<h1>”
> tag – possibly making documents using them completely unreadable in current
> browsers (and to anyone who thinks this is unimportant as “everybody will
> have the latest browser installed” – I know of many institutions, including
> my own employer, that still has IE6 on the desktop).
>
>
>
> Thirdly, there’s the mixing of semantics and presentation – something that
> the CSS aimed to separate. The tag’s name (which, as far as I understand, is
> every valid identifier character up to the first whitespace, or the end of
> the tag, whichever comes first) defines its purpose, not its presentation.
>
>
>
> Finally, a further thought on tag names: the element’s start and end tags
> are, I believe, required to have the same name. Thus, a hybrid tag would
> only save on typing only if a single class name was shorter than 7
> characters.
>
>
>
> <span.nifty>something</span.nifty>
>
>
>
> Is 2 characters short of its “traditional format”:  <span
> class=”nifty”>something</span>
>
>
>
> <span.embellished>something</span.embellished>
>
>
>
> Is 4 characters longer than: <span class=”embellished”>something</span>
>
>
>
> Jason L. Musgrove
>
> Web Application Developer
>
> University of Wolverhampton
>
>
>
>
>
> *From:* public-html-comments-request@w3.org [mailto:
> public-html-comments-request@w3.org] *On Behalf Of *T.J. Crowder
> *Sent:* 07 April 2010 22:26
> *To:* public-html-comments@w3.org
> *Subject:* Re: Alternate syntax for defining class attribute
>
>
>
> Hi all,
>
>
>
> I'd like to re-raise the below. I was just doing something yet again which
> (legitimately) involved a lot of elements with classes on them, and it was
> just so painful to write. There was no structural solution, it was the
> nature of the beast, lots of interspersed things requiring their own
> styling.
>
>
>
> Yes, it's not something that's going to happen soon (not in HTML5, I'd
> say), but taking the long view, I want to put it on the table for 5.1, 5.2,
> 5.5, 6, whatever. It's a very natural, straightforward, simple, concise
> approach, and yet with (I assert) minimal impact on any well-written parser.
>
>
>
> Recapping to save your reading through the below: The idea is to provide an
> alternate means of specifying a class on elements, by using the CSS syntax,
> e.g.:
>
>
>
>     <span.nifty>thing</span>
>
>
>
> equals
>
>
>
>     <span class="nifty">thing</span>
>
>
>
> That's the core idea. Saves eight characters (which is nice in an of
> itself; I assert that's typically going to be 50% *or more* of the text
> defining the class), but also unifies a bit with the CSS selector syntax for
> an element with a class.
>
>
>
> Potential extensions to the idea involve multiple classes:
>
>
>
>     <span."nifty spiffy">thing</span>
>
>
>
> ...but I don't think that's necessary at all if it over-complicates
> parsers.
>
>
>
> Naturally if class is also specified (I can see this happening with some
> tools), the result is a union:
>
>
>
>     <span.nifty class="cool">thing</span>
>
>
>
> equals
>
>
>
>     <span class="nifty cool">thing</span>
>
>
>
> Is this the right place to put this on the table, or if not, where would I
> do so?
>
>
>
> Thanks in advance,
>
> --
>
> T.J. Crowder
>
> Independent Software Consultant
>
> tj / crowder software / com
>
> www.crowdersoftware.com
>
>
>
>
>
> On 25 August 2009 04:28, Ian Hickson <ian@hixie.ch> wrote:
>
> On Sat, 15 Aug 2009, T.J. Crowder wrote:
> > >
> > > We've looked at doing this before, but it has a very poor backwards-
> > > compatibility story, unfortunately.
> >
> > Yes, again, I did make the point in my original post that using this
> > shorthand form would very much be a "caveat author" (author beware)
> > situation -- the effect in older UAs will not be as desired.  Very much
> > like the new tags.  I frankly wouldn't expect to get much use out of
> > this new shorthand form for a good 3-4 years while compliance comes up
> > -- but in 3-4 years, it would be quite nice to have, hence suggesting it
> > now.
>
> I think it would take a lot longer than 4 years, but in the meantime we'd
> have quite an unfortunate situation with respect to some browsers having
> very different results than others, etc.
>
>
> > > It wouldn't be that hard to parse, but it would only save you a 5
>
> > > keystrokes...
> >
> > Which is to say, frequently, half the total.  I think 50% gains are
> > worth pursuing.  But even more so, the alignment with CSS syntax is very
> > attractive and natural.
>
> I think what would be helpful would be to make a JS library that fakes
> this (by searching for elements with attributes that start with "." and
> adding them to the class="" attribute), and seeing if it gets adoption.
> That would provide interesting information for future developers of HTML.
>
> --
>
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
>
> ------------------------------
>
> Scanned by iCritical.
>
>
>