HTML Improvement: Shorthand class syntax

[T.J. Crowder]

Hi,

Well, I'll jump in. :-)

In 2009 I made a proposal to the HTML5 working group. I wasn't successful getting traction with them (I won't go into it, but I hope the jQuery Standards group has a better experience) but I still think the idea is a good one, so I'd like to put it to this group and see what you think, perhaps it's something you'd be interested in championing.

Here's the pitch:

Much as we try to use structure rather than the class attribute whenever possible (styling, hooking up events, etc.), there are still lots of times when nothing but the class attribute will do. (Look at the source of the very-useful http://es5.github.com/, for instance.) But applying the class attribute is long-winded. Consider this oft-repeated snippet from that page:

<b class="anno">Ⓐ</b>

Let's put a proposal on the table for an alternate shorthand syntax mirroring the basic CSS class selector:

<b.anno>Ⓐ</b>

This saves typing (one character of overhead instead of nine [or seven if you skip the quotes]) and file size as well. It's also nice how it ties things up between HTML and CSS.

You can have multiple classes, just as in CSS selectors:

<b.anno.foo>Ⓐ</b>

It may or may not be a good idea to allow quotes as well (<b."anno foo">Ⓐ</b>), but I prefer keeping this shorthand syntax simple (to encourage implementation by vendors!) and CSS-like; if you want to use quotes for multiple class names, use the long class= form.

A good way to look at this conceptually is:

• Allow tag names to be terminated with the dot (a change to Section 8.1.2.1, which currently defines that a start tag is terminated by a space or >)
  
• Allow the dot to be an alias for class=
• When processing the alias, use dot rather than space to delimit class names

Obviously this would be opt-in, the long form of the class attribute wouldn't be going anywhere. You should use one or the other on any given tag, though (just like you can't put multiple class attributes on a tag [just a single attribute with multiple values]).

This is only for HTML, not XHTML. This would be another of the convenience features of HTML over XHTML (just like optional quotes around attribute values that don't have spaces), of which there are several.

On the one hand, it would obviously take time (years, most likely) for the browser vendors to support this in their parsers, but browser vendors (even that one in Redmond) are being much more proactive these days, and the actual change to the parser shouldn't be very large at all. A lot less work, one would think, than supporting all of the implied tags defined by HTML5.

What do you think? :-)

--

T.J. Crowder

Independent Software Engineer

tj / crowder software / com

www / crowder software / com

[Jake Verbaten]

What about id's. Someone could argue that id's are too long.

instead of

<b id="foo">Ⓐ</b>

we should have

<b#foo>Ⓐ</b>

Now personally I don't think we need to shorten id selectors. But if we shorten class selectors how do you justify not shortening id selectors?

Also how do you gaurd againts this being the first step of html converging into haml?

[T.J. Crowder]

Thanks for the feedback! (Looking at your email address, are you the raynos I see on SO?)

On Tuesday, 25 October 2011 11:56:52 UTC+1, Jake Verbaten wrote:

What about id's. Someone could argue that id's are too long.

...

Now personally I don't think we need to shorten id selectors. But if we shorten class selectors how do you justify not shortening id selectors?

For me it's a frequency thing (I use class a lot more than id). That said, I could happily support your id idea, but I'm worried about introducing that much complexity. Having both the class and id shorthands leads inevitably to interactions between them and specifying how that works, e.g.:

<b#foo.bar>Hi</b>

...instead of

<b id="foo" class="bar">Hi</b>

...which I suppose is rational enough. HTML id values are allowed to contain dots, but the shorthand could be limited to the CSS definition (e.g., if you want a dot in your id -- shudder -- use id=).

I'm a bit surprised neither I nor anyone I've talked to about this previously has had your id idea. Nice one! Want to keep scope contained, but as class and id are two of the three central concepts (tagname being the third), it could make sense. Needs further discussion and input from others, because it does seem to me it complicates things.

 

Also how do you gaurd againts this being the first step of html converging into haml?

By ensuring that it isn't. :-) For me, your id idea is scope creep enough, the buck stops there.

[Jake Verbaten]

On Tue, Oct 25, 2011 at 12:14 PM, T.J. Crowder <t...@crowdersoftware.com> wrote:

Thanks for the feedback! (Looking at your email address, are you the raynos I see on SO?)

 

Yes.

On Tuesday, 25 October 2011 11:56:52 UTC+1, Jake Verbaten wrote:

What about id's. Someone could argue that id's are too long.

...

Now personally I don't think we need to shorten id selectors. But if we shorten class selectors how do you justify not shortening id selectors?

For me it's a frequency thing (I use class a lot more than id). That said, I could happily support your id idea, but I'm worried about introducing that much complexity. Having both the class and id shorthands leads inevitably to interactions between them and specifying how that works, e.g.:

<b#foo.bar>Hi</b>

...instead of

<b id="foo" class="bar">Hi</b>

...which I suppose is rational enough. HTML id values are allowed to contain dots, but the shorthand could be limited to the CSS definition (e.g., if you want a dot in your id -- shudder -- use id=).

I'm a bit surprised neither I nor anyone I've talked to about this previously has had your id idea. Nice one! Want to keep scope contained, but as class and id are two of the three central concepts (tagname being the third), it could make sense. Needs further discussion and input from others, because it does seem to me it complicates things.

 

Also how do you gaurd againts this being the first step of html converging into haml?

By ensuring that it isn't. :-) For me, your id idea is scope creep enough, the buck stops there.

The id example was merely scope creep. We really need a better way to contain scope creep. We can justify the need for a class variable.

I think since id's are unique you shouldn't just be creating a lot of such elements. the need for slapping a class on a small token is useful (<b> was a very bad example! Please use semantic examples like <strong>) and we can imagine that you can have _a lot_ of small tokens.

We can similarly justify the need for `<token#id>` because it's useful to slap id's on small elements for `url#tag` bookmarking. For example in HTML based documentation it would be very useful to have a lot of id's on elements so you can easily cross reference.

Now in both these cases these tokens would not have any other attributes then id's and classes and if they did have other attributes then we can just use the long hand form `name='value'`

So basically to shut down scope creep you must justify why there are a lot of elements with no attributes other then the one you want shortened.

I currently cannot think of any other elements where you would want just one attribute and where such elements with one attribute are in abundance.

As an aside now that I've justified this shortened form I can actually see that it's useful and not a perversion of HTML so +1 on this idea.

however we may want to disallow `<strong.foo extraAttribute="someValue">text</strong>` and only allow these elements with shortened class/id if they have no other attributes (this should be their purpose, right?)
 

[T.J. Crowder]

On Tuesday, 25 October 2011 12:29:16 UTC+1, Jake Verbaten wrote:

On Tue, Oct 25, 2011 at 12:14 PM, T.J. Crowder <t...@crowdersoftware.com> wrote:

Thanks for the feedback! (Looking at your email address, are you the raynos I see on SO?)

 

Yes.

Hi! :-)

 

I think since id's are unique you shouldn't just be creating a lot of such elements. the need for slapping a class on a small token is useful (<b> was a very bad example! Please use semantic examples like <strong>) and we can imagine that you can have _a lot_ of small tokens.

The b tag is still in the standard for a reason. :-) I actually thought the author of http://es5.github.com was using it exactly right (and I was doing something similar in my effort, until I found he and another had beat me to it). But let's not worry about the specific tag, div or span are just as good examples.

 

Now in both these cases these tokens would not have any other attributes then id's and classes and if they did have other attributes then we can just use the long hand form `name='value'`

I don't see any reason to restrict the content of the tag, and I see lots of reasons not to restrict it. I don't see any problem with:

<span.ts data-length="20" data-units="m">20 minutes</span>

Saying "and if you use this shorthand you can't have other attributes" complicates the parsing (reducing adoption by vendors) and doesn't seem on first glance to serve any purpose.

So basically to shut down scope creep you must justify why there are a lot of elements with no attributes other then the one you want shortened.

I'm not following you here.

 

As an aside now that I've justified this shortened form I can actually see that it's useful and not a perversion of HTML so +1 on this idea.

Thanks! :-)

[Jake Verbaten]

Saying "and if you use this shorthand you can't have other attributes" complicates the parsing (reducing adoption by vendors) and doesn't seem on first glance to serve any purpose.

I didn't think that through, your right it would complicate parsing.

I also think we can we can stop scope creep at id and class merely because they (and tagname) are the 3 central concepts. It doesn't make sense to try propose any other useful shorthand.

[T.J. Crowder]

On Tuesday, 25 October 2011 13:19:23 UTC+1, Jake Verbaten wrote:

I also think we can we can stop scope creep at id and class merely because they (and tagname) are the 3 central concepts. It doesn't make sense to try propose any other useful shorthand.

 

Agreed.

-- T.J. :-)

[The Configurator]

This sounds like a very interesting idea - which I fully support. However, how would jQuery Standards be able to move it forward?

[T.J. Crowder]

On Tuesday, 25 October 2011 14:18:39 UTC+1, The Configurator wrote:

This sounds like a very interesting idea - which I fully support. However, how would jQuery Standards be able to move it forward?

Thanks.

Well, I think that's the purpose of the group, isn't it? From the blog post:

The jQuery Standards Team has three primary goals:

• To represent the web developer community, in particular jQuery users, to standards bodies such as the W3C and TC39 with the intention of improving existing standards and standards in progress to better meet the needs of web developers.

• To represent the web developer community, and especially jQuery users, to browser vendors with the intent of helping them identify standards that they should prioritize for implementing, and proofs of concept that they can build.

• To help the jQuery project adopt new standards and browser features as appropriate.

This is, of course, relatively minor compared with (say) having control over headers and footers when printing from the browser (one of the items already on the list), but hey... :-)

[Filipi Zimermann]

Guys,

My observations:

1) It makes parsing complicated.

The syntactical structure of HTML will need some of variations. I think it is bad.

It becomes harder to build the parsers and HTML interpreters.

I think that for core structures like parsers, the leanest, the better.

2) I think it will get harder to read (as a human).

Specially when there will be lots of classes, there wont be some nice visual delimeters. 

I'll loose the focus on tag name, because there will be lots of other words in sequence...

Yes, I know, it's a very personal observation. Maybe, for someones it will be better to read. 

But... it's what I think.

3) I don't think that saving 9 characters per tag would make so much difference... 

compression exists for it...

---

I don't think it's a bad idea.

My intention is just to stimulate your arguing.

I'm not convinced it would make a great difference.

---

Have you ever tried to make a interpreter for that syntax?

Maybe you could build a "shorthand HTML compiler"... a tool that transforms a HTML on the shorthand syntax to a normal HTML syntax.

This way you can test the acceptance of your idea and maybe make some developers life a little better.

For me, your idea is related to HTML as http://cappuccino.org/ is related to Javascript.

Take a look at them and get some inspiration.

Cheers

[Paul Irish]

Have you ever tried to make a interpreter for that syntax?

 

I've been thinking the same thing

between haml and zen coding, it gets pretty close to what you're doing here.

[Eli Perelman]

-1 on this. I do believe there is a merit in wanting to improve the readability of our code, but I think the overhead in having to implement this far outweighs its benefits.

Since I can't see this solving any major problems, I think this falls more into the convenience category, and like Paul said, we already have things Haml, Jade, and other templating solutions that can abstract this from being inconvenient.

 

My two cents,

 

Eli Perelman

[Filipi Zimermann]

When I said Capuccino, I meant, http://jashkenas.github.com/coffee-script/ .. it is all with caffeine.. :P

[T.J. Crowder]

Hi all,

Thanks for the feedback.

A couple of people have said this makes parsing more complicated.
Compared with the overall task of parsing HTML, which is non-trivial,
adding two additional terminators for the start tag (`#` and `.` in
addition to the existing terminators space and `>`) and then handling
the id and/or class names following based on seeing one of those
charactesr should be *trivial*.

I'm not looking to go down the road of completely reinventing HTML
a'la HAML and such. I'm just talking about a _small_ addition of a
shorthand syntax to make it easier to apply classes (my primary
interest is classes, not IDs; I'm more than happy to drop the ID part
of it if it complicates things).

If I get a chance, I'll look at how hard it is to build Chromium[1] on
my machine (looks like it might be daunting[2], but achievable and
rewarding for several reasons). If I can, I'll look at diving into the
parser to see just how hard this really is. My gut says "not."

[1] http://code.google.com/p/chromium
[2] http://code.google.com/p/chromium/wiki/LinuxBuildInstructions

[Ben Boyle]

It is an interesting idea. I agree that zen coding gets pretty close to this, which is great in authoring tools. Maybe we need zen coding support live on more web servers, then browsers wouldn't need to know and we wouldn't need to convert.

Parsing complexity needs to take error handling into account. What do these mean?

<b#bar#foo>

<b#bar id="foo">

[T.J. Crowder]

On Oct 26, 1:04 pm, Ben Boyle <benjamins.bo...@gmail.com> wrote:
> It is an interesting idea.

Thanks!

> I agree that zen coding gets pretty close to
> this, which is great in authoring tools. Maybe we need zen coding support
> live on more web servers, then browsers wouldn't need to know and we
> wouldn't need to convert.

There are plenty of pseudo-HTML markups out there that require
preprocessing to become HTML. That's not what I'm trying to achieve
here. I'm trying to get HTML itself enhanced. Anything requiring pre-
processing by nature becomes second-class. There are lots of other
HTML changes being made that require changes to user agents, this
would just be another one.

> Parsing complexity needs to take error handling into account. What do these
> mean?
> <b#bar#foo>
> <b#bar id="foo">

Indeed it does. :-) If the ID thing were to be included in the
proposal (I remain on the fence), those would both mean this:

<b id="bar" id="foo">

What _that_ means is beyond the scope of the proposal. :-) My
understanding is that attributes must be listed only once (although
I'm not _immediately_ seeing that in the HTML5 spec, I'm probably just
not looking in the right place). A quick experiment[1] shows that
Chrome and Firefox both ignore the second one (this is true both for
`id` and for `class`, I assume it's true for other attributes as
well).

[1] http://jsbin.com/ohodil/2

[Domenic Denicola]

My thoughts: anything that is easily done with a preprocessor is not worth the standards bodies' time. This adds no new features to the web, but simply gives a second way of doing something, that to some people's eyes is nicer. There is no objective gain, only subjective, and there is nothing here that is any better than the myriad of other alternatives as exhibited by other compiles-to-HTML languages already mentioned.

More practically, the amount of work it would take to push this through expends valuable political capital. It wouldn't propagate to a large enough browser share for many years to come, and progressive enhancement cannot apply, so anyone wanting to use this in the interim would involve a preprocessor anyway. So it ends up being a wish that the W3C will bless your favorite flavor of pre-HTML over all others, with no actual benefit.

Strong -1.

[Dave Methvin]

I'd tend to agree with Domenic. I *like* the idea and the way it somewhat unifies the CSS and HTML syntax, but in practical terms we have much bigger fish to fry and this particular bikeshed already has a very durable coat of paint on it. 

We are all no doubt pretty busy with our day-to-day work. I would suggest we focus on ideas and proposals that address unresolved or ambiguous areas and allow us to do things that are slow, difficult or impossible today. 

[The Configurator]

<dom...@domenicdenicola.com> wrote:

My thoughts: anything that is easily done with a preprocessor is not worth the standards bodies' time. This adds no new features to the web, but simply gives a second way of doing something, that to some people's eyes is nicer. There is no objective gain, only subjective, and there is nothing here that is any better than the myriad of other alternatives as exhibited by other compiles-to-HTML languages already mentioned.

I disagree about this; if a feature is large, even if it can be done by a preprocessor, it can heavily affect the HTML. Otherwise, we wouldn't need defined tags at all - most of them can be defined with pure css, e.g. div { display: block; }, which can be added by the preprocessor.

However, in this case you can trivially write a preprocessor (or even JavaScript), so I agree with the political capital statement. While I like the idea very much, I don't think we're in the right place to move it forward - even if it is A Good Thing™.

[Jonathan Sharp]

"Ditto"

- JD

[T.J. Crowder]

On Oct 26, 3:53 pm, Domenic Denicola <dome...@domenicdenicola.com>
wrote:
> There is no objective gain, only subjective...

There is an objective gain: Smaller file size = reduced network
traffic. However, A) Probably only for a small set of files (ones that
need to constantly highlight words in a way that requires classes),
and B) Even for those, probably not that much (not even 10%, I
wouldn't think). Compared with what we're transferring across the wire
now (video), a trivial amount, so...

> More practically, the amount of work it would take to push this through
> expends valuable political capital.

I have two reactions to this:

1. The standards bodies should be working for us. We shouldn't need
political capital to get things done.

2. You're probably right. :-)

[Scott González]

On Oct 26, 11:29 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> There is an objective gain: Smaller file size = reduced network
> traffic.

Do you have actual statistics? I bet gzip makes this negligible.

[T.J. Crowder]

Did you read my message? Where I said it would probably be trivial?

But separately: gzip is great, but it can only work with what it has
to work with (and a shocking number of sites fail to use it). The
smaller the source material, in general the smaller the gzipped
result.

But again, I did say "trivial."

-- T.J.

[Giscard Girard]

Agree, the task of adding a class name to an element quickly is the responsibility of the IDE / preprocessor.

The file size is worth considering, but I suspect in real case scenarios there's probably many opportunities to avoid the use of a class name all together.

[Alex Ivasyuv]

I think if you want to use shothand syntax of css, we have to move everything from css to html in that case. In this case 

<div id="submit" class="green" data-client-id="e546"></div>

move to

<div#submit.green[data-client-id=e546]></div>

well, not bad, + we have already formatted css selector :)

[T.J. Crowder]

Hi,

I would prefer to do something very simple and targeted, but it's an
amusing idea. Of course, that attribute notation is actually *longer*
than the HTML if you need quotes around the attribute value (as you
would if it had whitespace in it).

For me, even the `id` thing is a step too far on the very simple
original "shorthand class notation" idea for HTML itself. But for some
kind of pre-processed format, sure. Of course, then people will want
to throw jQuery-isms into it:

<label><input[name=foo]:checkbox:checked> I'm pre-ticked!</label>

...to make things even more complicated. But I digress... :-)

[Ole Marius Løset]

Less bits goes on the cost of readability. I'd rather go with using
the zen coding bundle for textmate (or your favorite editor) and focus
on other ways of speeding things up - css/js combining, async loading,
compression etc.

If it's about saving network traffic, the only idea I can come up with
that might could work is to have a compressor on the server-side that
transform html+css into shorthand-html+css when requested and sends it
to the client-side where it gets transformed back into html+css
(eventually still compressed) and rendered in the browser. It'd
probably be a bit slower for the end-user, but less network traffic.

Then again, how important is it to save a few bytes today unless your
traffic cost millions?

[Filipi Zimermann]

"Move everything from css" is bad.
The colon will conflict with namespace notation.

It will turn things even more complicated for XML+namespace based pre-processors as JSF or taglibs like JSTL.

This is really a bad idea.
-10

--
Filipi Zimermann
http://www.nextt.com.br/
Mobile: +55 (48) 8479-7900
Office: +55 (48) 4052-9556

[T.J. Crowder]

On Oct 30, 1:24 pm, Filipi Zimermann <fil...@nextt.com.br> wrote:
> "Move everything from css" is bad.
> The colon will conflict with namespace notation.

[snip]

>
> This is really a bad idea.
> -10

Just being clear, this concept of going over-the-top with CSS notation
is *not* what I was proposing. I proposed just the `class` thing.
Raynos suggested adding `id`, which complicates things, and then Alex
wanted to go whole-hog. :-)

Personally, I prefer just the class bit. But it doesn't matter,
because:

I don't see critical mass on the original idea (or any other form of
it, frankly) being achieved. The only objective reasons for doing this
in HTML itself (as opposed to pre-processing) are A) file-size
reduction, and B) ubiquity.

A) File-size reduction

The gains almost certainly aren't sufficient that this is a viable
argument. I haven't looked at a really large number of examples, but
for instance my http://es5.github.com example goes from 1,321,219
characters to 1,266,155, a reduction of 55,064 characters or about
4.2%. The "questions" page from Stack Overflow did a bit better, ~6%.
But these are smallish reductions in HTML page size, when most traffic
(by volume) these days is images, audio, and video. Not a big selling
point, I wouldn't have said.

B) Ubiquity

Ubiquity is an objective argument, but only if people want to use the
shorthand form, which is a subjective gain.

So that leaves us with subjective arguments, how it nicely marries up
CSS and HTML syntax and makes it really easy to see at a glance what
variant of element you're dealing with (p.biblio vs. p.footnote vs.
p.caption, from the ES5 example). *I* think there's a lot to that, but
it's lonely out here. :-) If everyone had looked at this idea and said
"Hey, yeah, that's great! I'd really like to use that!" then it might
be worth pursuing. But that didn't happen (or at least, that's not how
I read the responses in this thread). Which I think is too bad, but
that's just my opinion, which appears to be in the minority.

So barring a lot of people suddenly rising up saying "I really want to
use that!" I'd say the idea is dead. Move along, nothing to see
here...