Re: Alternate syntax for defining class attribute

On Fri, Apr 9, 2010 at 11:05 PM, Musgrove, Jason L
<J.L.Musgrove2@wlv.ac.uk> wrote:
> 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 *not* SGML. The main reason for this is that no browser has
ever parsed HTML as by SGML rules; and there is no reason to think
that browser vendors are planning to change that. Thus, it makes no
sense to specify something that doesn't match, and will never match,
reality. Even if we could convince browser vendors to switch to
SGML-compliant parsing, that's not something we want, since it would
cause a huge amount of legacy content to miserably break (for example,
all the "XHTML as text/html" content would start breaking at the first
<meta />, <link />, or any other self-closing tag; and that's likely
to be quite early on the document).

Thus the HTML5 spec has the ability to define syntax sugar features
like this one. Whether it should or not is another story.

> 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).
That's, IMO, the strongest and soundest argument against the proposal;
and I fully agree with it.
It's not unsolvable, however. A possible solution would be to allow
whitespace before the dot; and recommending its inclusion until
pre-HTML5 browsers die off (just like many features recommend the use
of their different fallback mechanisms during this "transition
period").

> 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.
There is no such mixing. The element name defines the basic structural
role of the element and, *sometimes*, part of its semantics. The class
attribute is there to allow further semantic categorization without
having to define all possible categories (which are probably infinite)
as HTML elements. This was true for HTML4, and is even truer for
HTML5, since the spec adds emphasis on that purpose.
The fact that CSS can easily hook to class values doesn't make the
class attribute presentational. CSS can also hook on ID's, and that
doesn't make the id attribute presentational. Even further: the
simplest CSS hooking available is the Type selector: does that make
each element presentational?
Also note how Microformats, a purely semantic technology, relies
entirely on the class attribute. I hope you don't attempt to claim
that Microformats are presentational just because of that.

I'll concede that *typical usage* of class has been much more
presentational than it should, most prominently among hobbyists and
newbies who would happily use stuff like <font> and the like anyway;
but presentational class names are well known to be a bad idea even on
practical aspects (especially for the maintenance issue), so I would
be surprised if such uses among serious pages (ie: pages written by
people who take web authoring seriously) was too higher than other
obnoxious html3.2ish stuff.

> 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.
Who says that the dot and class name would be part of the element
name? SGML maybe?
Being the syntax sugar kind of feature this proposal is; it seems to
be that the simplest way to implement it would be on-the-fly
replacement upon parsing, so after parsing something like "<span.nifty
" the browser would end up exactly on the same state as after parsing
something like "<span class='nifty' >". Thus the end tag it would be
expecting would be "</span>" rather than "</span.nifty>".


My opinion on the proposal:

The idea itself is not bad. It does provide a benefit (even if a minor
one). It has, however, a significant specification and implementation
cost; in addition to very brittle fallback behavior on legacy
browsers.
There is a lot of stuff for UAs to implement in HTML5, and most of it
is far more substantial than syntax sugar. The web *needs* those
features, and needs them *soon*. Which means that HTML5 needs to shave
off superfluous additions. HTML5.1 or HTML6 will be another history;
and isn't likely to take as long as HTML5 is taking (because HTML5 had
to define too much stuff from zero).

So I have to stand against this proposal now. I encourage you to bring
it forth again when work for the next version of HTML begins, and
you'll have my support.


(Sorry for the "manual" quoting here, but quoting the fragment quotes
on the original post was getting close to nonsensical)

>> Quoting (presumably) T.J. Crowder <tj@crowdersoftware.com>
>> > But even more so, the alignment with CSS syntax is very
>> > attractive and natural.
I'd rather take this as an argument *against* the feature. Big efforts
have been taken since HTML4 and CSS came out to make authors
understand that @class is not a mere CSS hook, but a semantic
extension mechanism.

> Quoting Ian Hickson <ian@hixie.ch>
>> 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.
I definitely agree with Ian's suggestion here. A JS-based
implementation can serve as a temporary solution *and* double as an
implementation feedback source when this is brought in again for the
next iteration of the language.


Regards,
Eduard Pascual

Received on Friday, 9 April 2010 22:46:39 UTC