These forums are currently read-only due to receiving more spam than actual discussion. Sorry.

It is currently Sat Dec 02, 2017 4:17 pm Advanced search

all tags should have all attributes

Do you think the HTML spec should do something differently? You can discuss spec feedback here, but you should send it to the WHATWG mailing list or file a bug in the W3C bugzilla for it to be considered.

all tags should have all attributes

Postby ronald.denenea » Thu Dec 06, 2007 1:50 pm

tags should be customizable so that css is easier and then more attributes in other scripts or languages can be added. this would include tags to be any name but have all attributes available so that any new tag can be any pre-existing tag making the class, name, and id attributes less used.
ronald.denenea
<h6>
 
Posts: 3
Joined: Wed Dec 05, 2007 2:09 pm

Postby zcorpan » Mon Dec 10, 2007 6:46 pm

It's not clear to me what the problem is that you're tying to solve here.
zcorpan
<article>
 
Posts: 807
Joined: Tue Feb 06, 2007 8:29 pm
Location: Sweden

Postby ronald.denenea » Sat Feb 02, 2008 4:28 pm

if the tags are customizable then the css and javascripts will be easier, and will lessen the use of id="", name="" class="". since it is easier to position things with divisions the tables are going away, so instead of having <table></table> or <div></div> allow tags like <rssfeed></rssfeed> or <randomjunkinthecorner>... existing tags will probably still exist, but it makes css much easier and shortens code. and allowing all attributes on all codes would allow for easier positioning of what used to be iframes, embed, img, and any other media, you could have a table and instead of nesting the i frame or video into the center cell, the cell itself would have a src="" attribute.
ronald.denenea
<h6>
 
Posts: 3
Joined: Wed Dec 05, 2007 2:09 pm

Postby zcorpan » Mon Feb 04, 2008 12:27 am

ronald.denenea wrote:if the tags are customizable then the css and javascripts will be easier, and will lessen the use of id="", name="" class="". since it is easier to position things with divisions the tables are going away, so instead of having <table></table> or <div></div> allow tags like <rssfeed></rssfeed> or <randomjunkinthecorner>... existing tags will probably still exist, but it makes css much easier and shortens code. and allowing all attributes on all codes would allow for easier positioning of what used to be iframes, embed, img, and any other media, you could have a table and instead of nesting the i frame or video into the center cell, the cell itself would have a src="" attribute.

So I understand it that you have two requests:

1. Allow custom elements.

because:

a) <foo> is shorter than <div class=foo>
b) foo { } is shorter than .foo { }
c) getElementsByTagName() is simpler than getting elements by classes

(a) and (b) are valid but don't have much weight here. (c) should be addressed by getElementsByClassName().

Disadvantages of allowing custom elements:

a) it makes it harder to extend HTML in the future
b) it becomes impossible to catch typos in element names when validating
c) while some authors think they're being "semantic" with their custom elements, consumers don't understand the semantics at all.



2. Allow all attributes on all elements.

because:

a) You get less elements to apply styles to when using embedded elements.

Browser vendors have said that this is extremely hard if not impossible to implement. Moreover, some attributes have the same name but different meanings when set on different elements (like type='' on link, script, style, ol, menu, input, embed, object...). Finally, this would not be backwards compatible.
zcorpan
<article>
 
Posts: 807
Joined: Tue Feb 06, 2007 8:29 pm
Location: Sweden

Postby ronald.denenea » Sat Aug 02, 2008 2:42 pm

The point is that the corresponding tags will be easier to correct not harder, and if all the attributes were the same then there would be no updating for specialized tags. new attributes would be the only reason for updating html and xhtml. plus the semantics of each coder may not be the same, but some coders dont want others to understand their coding, so it isn't stolen. when you use tags like <rssfeed> or <video> then it will be more clear what your intent was for that element. couldn't the backwards compatibility be increased or alleviated by a javascript attatched to the page, much like the one for opacity in ie 6 and down.
ronald.denenea
<h6>
 
Posts: 3
Joined: Wed Dec 05, 2007 2:09 pm

Postby Pacoup » Mon Aug 18, 2008 5:31 pm

Right...just write your own language in XML and style it with XSLT...T_T

- I don't understand how making more tag soup is going to help anyone.

- As for stealing, I think this is just bogus. You can't steal HTML, that's ridiculous. You can steal it's content, but otherwise the code is all the same and that's all for the better!
The same goes for intelligent server side code, one the biggest problem with PHP communities is how its users are so proud of their unique code. That's not cool, who cares if someone steals your code, at least multiple people can work on it, it's not like you invented the first server side web gallery. That's why framework based environments such as Django or Ruby on Rails are so easy to work with, everyone's code is the same! Let's not make the same mistake in HTML 5.

- There is some sense in the attributes everywhere stuff though. Href should be in almost all elements, like class is. The approach is easier for web developers to understand and makes cleaner code.
However, at the implementation level, you have to think that it doesn't make any sense that action="post.php", for example, would be in an <img>.

- As for more attributes in other scripts and programming languages, I believe in page scripts and server side code does this very well already. Scripts and the such should never be directly alongside the HTML code itself in my opinion, for the exception of a few cases, which is why it's possible at all with Javascript.

- Extensibility was also mentionned. I don't see how limiting the update of a few tags every 20 year but updating only attributes would help. If we were to do that, why not eliminate every tag and define everything via attributes and CSS classes. While we're at it, why not define the tags ourselves and skip the attributes when we don't need it? Sounds familiar? XML anyone?
I love XML, but for the things it does well, and web sites doesn't seem to be one of them. Let's not try to immitate something that already exists. If you like the idea of fewer tags and more global attributes, why not go talk to the closed XHTML 2.0 team, or better yet, learn XML. One of the strongest point of HTML 5 is that the XML approach is bad for web sites, and that certainly makes sense when you dive in applications, which is exactly the orientation of HTML 5. If you want a pure example of what I'm saying, try to make a forum page out of XSLT and XML only. XML is very well adapted to textual content yes, but web sites go well beyond traditional linear text. Just look at how RSS excels with XML, by now you should understand what I'm talking about.

My counter-proposition
I believe revising where attributes may be useable could be a good idea. For the sake of not breaking backwards compatibility, this does not mean we have to remove attributes such as href from <a>, but we could certainly use the href elsewhere. Let's cut the crap about being different from XHTML 2 just because it's HTML 5, some of their ideas are better. Notably the decision to make images containable in almost any block element, or their decision to include href in more than the <a> tag as mentionned.
User avatar
Pacoup
<h5>
 
Posts: 12
Joined: Mon Aug 18, 2008 2:20 pm
Location: Canada, Ontario, Ottawa

Postby JAB Creations » Tue Aug 26, 2008 11:32 pm

I have to disagree here save for tab attribute on divisible elements.

Am I the only one who sees red flags going off like it's the last day of existence with stuff like <all_elements href="virus.exe" />? :roll:
User avatar
JAB Creations
<aside>
 
Posts: 566
Joined: Tue Mar 13, 2007 4:48 am
Location: Sarasota Florida, USA


Return to Feedback on the Specs

Who is online

Users browsing this forum: No registered users and 0 guests