RE: Alternate syntax for defining class attribute

T.J.,

 

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?

 

<style>

.nounderline {

            .

}

</style>

 

<a nounderline href="." >.</a>

 

So, since <a> doesn't have a nounderline property the UA looks for a style
by that name, if found the UA uses that style otherwise the attribute is
ignored.

 

Older browsers not supporting the feature should ignore nounderline and
render <a> normally.

 

You could also make it so that if a valueless attribute exists anywhere in
the tag that the above logic would apply. But then one has to consider the
possibility that someone will put in two of these attributes on the same tag
at which point what would the behavior be?

 

Art 

 

 

  _____  

From: public-html-comments-request@w3.org
[mailto:public-html-comments-request@w3.org] On Behalf Of T.J. Crowder
Sent: Friday, April 09, 2010 3:00 PM
To: Musgrove, Jason L
Cc: public-html-comments@w3.org
Subject: 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. 

 

 

Received on Friday, 9 April 2010 22:30:48 UTC