PDA

View Full Version : Custom tags! Can it be true?



Bill Byrd
04-19-2014, 03:38 PM
(Preliminary forum-search performed)

As a rookie I'm bound to discover amazing things that you guys have been using for years. I use a lot of surgical text coloring for clarity. A typical line of HTML might look like this for me.

Declare a <span class="G">variable</span> <span class="R">dog</span> with a <span class="B">value</span> of <span class="O">animal</span>.

I was just wondering how nice it would be if I could use something like <G></G> rather than <span class="G"></span> to color a word green. So I Goggled it and found that "tag, charcter, hyphen, character, tag" could be used. I tried it in Chrome, FF, IE. I was shocked that it actually worked. Is there some catch, something I'm missing? This seems too good!

With custom tags: Declare a <x-G>variable</x-G> <x-R>dog</x-R> with a <x-B>value</x-B> of <x-O>animal</x-O>.

x-G{
color:green;
}

xelawho
04-19-2014, 05:42 PM
A nice little discussion of custom elements here:
Custom Elements: defining new elements in HTML - HTML5 Rocks (http://www.html5rocks.com/en/tutorials/webcomponents/customelements)

Bill Byrd
04-19-2014, 07:14 PM
A nice little discussion of custom elements here:
Custom Elements: defining new elements in HTML - HTML5 Rocks (http://www.html5rocks.com/en/tutorials/webcomponents/customelements)

Thank you. Purely by chance-- that's where I got my info.

VIPStephan
04-19-2014, 07:29 PM
That’s actually new to me. But it makes me wonder why it’s still called “HTML” at all then because that’s everything except what HTML was originally created for. And it makes me wonder why so much energy is wasted to establish such a “workaround” when there is XML which does exactly the same and is exactly made for such applications? All in all, it makes me question the development things took with HTML 5 even more.

Bill Byrd
04-19-2014, 07:50 PM
That’s actually new to me. But it makes me wonder why it’s still called “HTML” at all then because that’s everything except what HTML was originally created for. And it makes me wonder why so much energy is wasted to establish such a “workaround” when there is XML which does exactly the same and is exactly made for such applications? All in all, it makes me question the development things took with HTML 5 even more.

I know nothing of XML. When I got bitten by the bug in mid-2011, I was at the mercy of videos and books and forums. I wanted to be sure I wasn't learning how to make horseshoes in a world where cars had just been invented. And, right or wrong, I got the impression that XML was used-to-be and HTML was the thing to learn (and since then, HTML5 in particular). As a pure rookie, especially to JS, I can't imagine why you wouldn't want the ability to declare a tag. The page I'm building right now has <x-g>word</x-g> where I was using <span class="g">word</span> only yesterday. I know it's not a huge deal. But it does add up.

Five times:<span class="g">word</span><span class="g">word</span><span class="g">word</span><span class="g">word</span><span class="g">word</span>

Five times:<x-g>word</x-g><x-g>word</x-g><x-g>word</x-g><x-g>word</x-g><x-g>word</x-g>

felgall
04-20-2014, 12:07 AM
I know nothing of XML.

Not true - the code you are posting is XML. All you need to do is to add the appropriate doctype to define what your invented tags mean to the top of the code.

<x-g>word</x-g><x-g>word</x-g><x-g>word</x-g><x-g>word</x-g><x-g>word</x-g>

Bill Byrd
04-20-2014, 01:39 AM
Not true - the code you are posting is XML. All you need to do is to add the appropriate doctype to define what your invented tags mean to the top of the code.



Well, I guess it should come as a surprise to no one that a rookie who thinks he's using HTML is typing XML. I'll have to study up and find out what the difference is. As to the invented tags-- they are defined in my CSS.

<x-g>words</x-g>

x-g{
color:green;
}

Bill Byrd
04-20-2014, 02:05 AM
Well, I went to w3schools and got a very cursory lesson on XML versus HTML. I learned how ridiculously wrong I was in thinking that XML was an obsolete version of HTML. In reality, it's something altogether different. As one of the prerequisites to their XML courses, they list JavaScript. Since I'm only just now scratching the surface at doing that-- I guess I can be forgiven for not knowing doodly about XML. But-- I'm still left wondering if it's okay for me to use my homemade tags. The do "work" in the various browsers. But I suspect that merely working is different from proper form. Maybe a peek at my source-code might reveal any unforgivable sins to those of you who know them when you see them 77sunset.com (http://www.77sunset.com).

PS: If you think I have a lot of nerve offering quizzes when I'm only just learning, it's because it helps me to learn.

Thanks

tracknut
04-20-2014, 03:24 AM
Personally I wouldn't make up tags as you're doing. Even if it works (it won't work in older versions of IE certainly), it does not validate (http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.77sunset.com%2F), and would be seen as bogus html by anyone needing to maintain your code. Better (imo) to redefine other known tags (<b>, <i>, <em>, etc) for this purpose.

rnd me
04-20-2014, 07:27 PM
custom HTML5 tags are still html5. the newer Web components standards allow you to give your custom tags specific behavior. CSS has always allowed custom tags to have their own presentation. Custom tags work in all browsers, so there's no compelling reasons, other than philosophical/academic ones, not to use custom tags. These tags will work in older IE if you you the "HTML5 shim" technique of dynamically creating a single instance of the tag in JS in order to populate IE's tagName pool. for example, running document.createElement("g") just once at some point, would be needed to make IE<9 style your <G> tag.

Custom HTML5 is NOT the same as XML. Don't bother with XML, it's slowly dying a deserved death as the stronger data interchange format of JSON gains programmer preference. I also wouldn't let some silly validator 2nd-guess real-world testing on the devices you intend to support. the real world is FAR more important than the academic, and validation ensures you align with a minimal feature set, not the full available feature set. While w3 validation is great at catching errors like missing close tags, many of its warnings and errors can and should be safely ignored. It's experience that teaches you the advantages and limits of such a tool, guiding you make better apps more than dogmatically enforcing a lack of imagination.

i also take exception to tracknut's suggestion that existing HTML5 tags should be semantically abused for presentation purposes. B, I, and EM have specifics meanings to documents and AT. It would be better to either use custom classes (within validation) or custom tags (within semantic guidelines). That said, look into some of the newer standard HTML5 tags, article, aside, figcation, header, footer, template, and others might fill the gap of tag names your custom tags seek to fill.

tracknut
04-20-2014, 08:07 PM
i also take exception to tracknut's suggestion that existing HTML5 tags should be semantically abused for presentation purposes. B, I, and EM have specifics meanings to documents and AT. It would be better to either use custom classes (within validation) or custom tags (within semantic guidelines). That said, look into some of the newer standard HTML5 tags, article, aside, figcation, header, footer, template, and others might fill the gap of tag names your custom tags seek to fill.

He's using his custom tags to emphasize certain words in paragraphs, which to me is much closer to calling them "emphasized" or "bold" than it is to call them "arcticles" or "asides". But to each his own...

VIPStephan
04-20-2014, 08:34 PM
I also wouldn't let some silly validator 2nd-guess real-world testing on the devices you intend to support. the real world is FAR more important than the academic, […]

i also take exception to tracknut's suggestion that existing HTML5 tags should be semantically abused for presentation purposes. B, I, and EM have specifics meanings to documents and AT.

Well, to add some criticism to the HTML 5 approach: <b>, <i>, and <u> used to be presentational elements in HTML (up to version 3) whose use rightfully had been frowned upon and deprecated in HTML 4, and have just been redefined and an artifical meaning imposed on them in HTML 5 because the decision makers were afraid of breaking with old habits. And “coincidentally”, the default visual styles of these elements are the same as they have always been (<b> is printed bold, <i> is italic and <u> is underline), and the semantics have just been constructed around the styling.

And this is where the “real world” vs. the “academic world” issue comes into play because the “real world” is exactly what’s unreflectingly adding more and more crap to the world just because it fits for the moment and specific application while the “academic world” tries to thoughtfully define the standards in advance according to a “universal order”, to ease development in future. What’s called “HTML 5” today is basically just the result of ignorance, lazyness, and stupidity winning over vision and reason. So much energy is wasted by reinventing the wheel multiple times while life for all of us as developers could be and have been so much easier for years already if the “academic world” wouldn’t be seen as useless and annoying millstone around the neck.

Why HTML at all then? Why not create a totally new “web application markup language”? Which leads to the question: Why not use XML? To me it makes no sense to reinvent the wheel. But perhaps the “real world developers” always need something new to do to give their lives a meaning.

Bill Byrd
04-20-2014, 10:18 PM
Better (imo) to redefine other known tags (<b>, <i>, <em>, etc) for this purpose.

That's something else I didn't know you could do. Also very cool.

b{
font-style:italic;
color:red;
}

<b>Something else I didn't know</b>

Still not sure though why this wouldn't be as egregious a sin (to the purest) as some other homemade tag like the one I came up with for green: <x-g>.
Just trying to sort things out.

Bill Byrd
04-20-2014, 10:29 PM
" I also take exception to tracknut's suggestion that existing HTML5 tags should be semantically abused for presentation purposes. B, I, and EM have specifics meanings..."

Wow! A lot to take in with that post. I just got through celebrating Tracknut's advise regarding the molesting of existing tags, a position which you clearly disagree with per the statement above! It's particularly hard for a learner like me to know what to embrace. What you said really felt right though. What I need to do is stay on point with my JS lessons and quit getting distracted with trying to make my project page look better. And that's just exactly what I'm going to do.

Bill Byrd
04-20-2014, 10:35 PM
Well, to add some criticism to the HTML 5 approach: <b>, <i>, and <u> used to be presentational elements in HTML (up to version 3) whose use rightfully had been frowned upon and deprecated in HTML 4, and have just been redefined and an artifical meaning imposed on them in HTML 5 because the decision makers were afraid of breaking with old habits. And “coincidentally”, the default visual styles of these elements are the same as they have always been (<b> is printed bold, <i> is italic and <u> is underline), and the semantics have just been constructed around the styling.

And this is where the “real world” vs. the “academic world” issue comes into play because the “real world” is exactly what’s unreflectingly adding more and more crap to the world just because it fits for the moment and specific application while the “academic world” tries to thoughtfully define the standards in advance according to a “universal order”, to ease development in future. What’s called “HTML 5” today is basically just the result of ignorance, lazyness, and stupidity winning over vision and reason. So much energy is wasted by reinventing the wheel multiple times while life for all of us as developers could be and have been so much easier for years already if the “academic world” wouldn’t be seen as useless and annoying millstone around the neck.

Why HTML at all then? Why not create a totally new “web application markup language”? Which leads to the question: Why not use XML? To me it makes no sense to reinvent the wheel. But perhaps the “real world developers” always need something new to do to give their lives a meaning.

Ouch! Didn't mean to stir up controversy. I just wanted to know if I could catch a break on all the <span style="color:#666;"></span> . Just seems so clunky.

tracknut
04-20-2014, 11:15 PM
That's something else I didn't know you could do. Also very cool.

...

Still not sure though why this wouldn't be as egregious a sin (to the purest) as some other homemade tag like the one I came up with for green: <x-g>.
Just trying to sort things out.

Because (and I'll put IMO in uppercase since there are people on the other side of the argument) <b>, <i>, (see also <em>, <strong>, <dfn>, <code> etc which may also be of interest) are much closer semantically to your purpose than <x-g>, which means nothing. In other words, someone, or some *thing* that reads through your html code is more likely to understand the point behind <em>the meaning of life</em> than <x-g>the meaning of life</x-g>.

felgall
04-21-2014, 12:00 AM
Don't bother with XML, it's slowly dying a deserved death as the stronger data interchange format of JSON gains programmer preference.

The 1% of places where JSON can be used instead of XML is not going to affect the use of XML all that much.

Microsoft certainly isn't going to switch from XML to JSON for storing word and excel documents - not after all the troulbe that they went to to convert from a proprietary format to XML.

There are many uses for XML where JSON is not an even remotely practical alternative.

Bill Byrd
04-21-2014, 12:30 AM
"... are much closer semantically to your purpose than <x-g>, which means nothing."

I see. And that makes sense. Thanks for explaining.

On the other side, if semantics and context are more important than economy, my <x>baseball..., would have to give way to <adultLanguage>Baby, you really turn me on...

I know we've drifted somewhat from JS, but styling is relevant. And so, can you tell me, aren't the semantic tags exclusively for SEO (not that there's anything wrong with that)?

xelawho
04-21-2014, 12:41 AM
In other words, someone, or some *thing* that reads through your html code is more likely to understand the point behind <em>the meaning of life</em> than <x-g>the meaning of life</x-g>.

mmm... but if you're hijacking tags to the point of Bill's example:


b{
font-style:italic;
color:red;
}


in my view it runs counter to that argument, being that someone can read your code and *think* they understand it but actually be completely mislead.

kind of like keeping your kerosene in a bottle labelled "cough medicine" if you'd like a ridiculously extreme analogy.

Arbitrator
04-21-2014, 04:29 AM
But-- I'm still left wondering if it's okay for me to use my homemade tags. The do "work" in the various browsers. But I suspect that merely working is different from proper form.You shouldn't be using custom elements/tags in any HTML page published to the Web. Custom elements may be meaningful to you, but are completely meaningless to automated tools such as search engines. Element names like x-gn aren't particularly useful to other humans either.

(If you really want to use custom elements, you can write documents in your own syntax and transform them into an HTML/XHTML document on the server using an XSLT style sheet. The post-transform, Web-facing code will still use standardized elements that automated tools can understand. You'd have to be a real code geek like myself to want to go through all the trouble though.)


Maybe a peek at my source-code might reveal any unforgivable sins to those of you who know them when you see them 77sunset.com (http://www.77sunset.com).Per the HTML5 spec, you should be using HTML along these lines:


<code class="html-attribute-value">"unique"</code>
<code class="javascript-string">"pet"</code>
<b class="variable-description">dog</b>
<b class="value-description">animal</code>
<b class="number-description">$50</b>
<b class="variable-description">shipping</b> <b class="number-description">cost</b>
<b class="variable-description">total cost</b>
<b class="number-description">19</b>


b { font: inherit; }
.html-attribute-value, .javascript-string, .variable-description { color: lime; }
.value-description { color: aqua; }
.number-description { color: hsl(8, 100%, 50%); }

If you want to get really specific (and verbose), the following is also correct, IMO:


<code class="block">
[...]<code class="html-attribute-value">"unique"</code>[...]
[...]<code class="javascript-string">"pet"</code>[...]
</code>
<code class="javascript-variable">dog</code>
<code class="javascript-unquoted-string">animal</code>
<span class="javascript-number">$<code>50</code></span>
<code class="javascript-variable"><var>shipping</var></code> <code class="javascript-number"><var>cost</var></code>
<code class="javascript-variable"><var>total cost</var></code>
<code class="javascript-number">19</code>


code, var { font: inherit; }
code.block { display: block; font-family: monospace; }
.html-attribute-value, .javascript-string, .javascript-variable { color: lime; }
.javascript-unquoted-string { color: aqua; }
.javascript-number { color: hsl(8, 100%, 50%); }

In the latter case, var indicates that the value is a stand-in value rather than a literal value (that the quiz answerer is supposed to create or figure out).

You can shorten class names to whatever you want (like, say, jsn) since class names have no semantic value as far as the HTML spec is concerned. (While not required, the spec does say "authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content".)


custom HTML5 tags are still html5. the newer Web components standards allow you to give your custom tags specific behavior. CSS has always allowed custom tags to have their own presentation. Custom tags work in all browsers, so there's no compelling reasons, other than philosophical/academic ones, not to use custom tags.See above. Custom, micro-syntaxes shouldn't be encouraged on the Web for semantic reasons.


That's something else I didn't know you could do. Also very cool.

b{
font-style:italic;
color:red;
}

<b>Something else I didn't know</b>

Still not sure though why this wouldn't be as egregious a sin (to the purest) as some other homemade tag like the one I came up with for green: <x-g>.
Just trying to sort things out.Per the HTML5 spec, the b element's content is defined as "a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood". So there's nothing wrong with italicization; the element is no longer explicitly tied to bold text as it was in HTML 4.

For reference, the HTML spec is found at HTML Standard (http://www.whatwg.org/specs/web-apps/current-work/multipage/).

VIPStephan
04-21-2014, 10:52 AM
Per the HTML5 spec, the b element's content is defined as "a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood". So there's nothing wrong with italicization; the element is no longer explicitly tied to bold text as it was in HTML 4.

But that’s exactly what I was taking about and criticizing because what’s the point of that definition? There is none except to create a lame excuse to continue using presentational elements. Besides, HTML elements always bore a specific meaning in their very names, like “p” for “paragraph”, “ul” for “unordered list”, “dfn” for definition – and “b” for “bold”, “i” for “italic”, and “u” for “underline”. What the decision makers did with the latter three in HTML 5 is just like putting a “valid HTML 4 transitional” badge on a website: They just put a “valid” label on a pile of crap and make bad practice good practice just by changing the definition.

Bill Byrd
04-21-2014, 04:42 PM
Jeez! I'm clearly unqualified to be discussing something like this. I've had the "programming as it applies to the web" bug since mid 2011 after trying to help my grandson learn HTML. I had never even seen the stuff before. I can't shake the bug, but there's an ever-present invisible little guy sitting on one shoulder telling me "You ain't even close to being smart enough to sort all this stuff out. Ditch the idea." The little guy on the other shoulder says "Surely to God there's some way to boil this stuff down so that you can grasp it." So the debate goes on. At 68y/o I don't know why I love it so. There's no one even suggesting they'll hire me to build a site. I do certainly appreciate all the input though.

rnd me
04-21-2014, 07:00 PM
“b” for “bold”, “i” for “italic”, and “u” for “underline”. What the decision makers did with the latter three in HTML 5 is just like putting a “valid HTML 4 transitional” badge on a website: They just put a “valid” label on a pile of crap and make bad practice good practice just by changing the definition.

the only thing that had defined "good practice" before html5, was the last version of the spec, which you don't appear to have many issues with. I think html3 was about getting it out the door, and html4 was about rich documents. html5 strives to make the browser an application widget library host while keeping the best document-centric features from html4. It's a recognition that xhtml/xml never took off, and that the web can be used for more than just hyperlinked documents. This is a good thing because it moves applications out of flash and java and into an area where AT can make the GUI meaningful to everyone. I suppose some people like the strictness of html4, but heavy-handed requirements were dropped wherever extra machine work could make up the difference, like quoting attribs for example. this makes html more robust than prior implementations.

but, back to the main topic i wanted to address:
i rather like that they span-ized "B", it's the perfect tag for <label><b>Name</b><input name=name/><label>. it's nice that the "B" no longer implies a semantically meaningful thing like it did in html4 because it lets you use it for presentation without causing implications upon screen reader interpretation. it's much nicer in the markup than <span role=presentation class=bold>...

same for <i>: a (semantically) meaningless version of EM. By forking the presentation and semantic tags, HTML5 allows both short only-visual upgrades and meaningfully markuped-up documents, a line prior versions tried to straddle but inevitably fell short doing.

Arbitrator
04-22-2014, 06:18 AM
But that’s exactly what I was taking about and criticizing because what’s the point of that definition? There is none except to create a lame excuse to continue using presentational elements.The new definition is essentially "readability enhancement" or "attention getter" with the following caveat:


The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

I'm not sure how useful that is from a data-mining (semantic) perspective, but it's more meaningful and easier to type than a span element.