Re: Alternate syntax for defining class attribute

Hi,

Thanks again, all, for the comments.

First off, there's no question in my mind that this proposal will not be
part of HTML5. For one thing, we're after last call, aren't we? Even if the
idea had been met with universal acclaim, it's too late in the process, and
as Eduard said, we want browsers to implement HTML5 sooner rather than later
and don't want to trip that up at all. So I'm pre-flighting this for 5.1.

This is interesting. Ian said:

> 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)

Art said:

> What if for backward compatability you drop the dot and make it so
> if there is a valueless attribute following the tag name then look
> for a style by that name?

...which is similar, and Eduard said:

> A possible solution would be to allow
> whitespace before the dot; and recommending its inclusion until
> pre-HTML5 browsers die off

There is a lot of sense there (not surprisingly), and very nearly a
consensus. I think Eduard put it most clearly: An optional space before the
dot, and recommending including it until old browsers die off.

So the target convenience syntax is:

<span.nifty>foo</span>

...with an optional space, which is recommended during a transitional phase;
a stepping stone as it were:

<span .nifty>foo</span>

I will write up that library to process these and let the group know about
it. Give me a few weeks, I'm on deadlines in other work.

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


On 9 April 2010 23:45, Eduard Pascual <herenvardo@gmail.com> wrote:

> 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
>