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.   `._.-(,_..'--(,_..'`-.;.'
>